[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #1005 was SUCCESSFUL (with 2423 tests)
--- Spring Data GemFire > Nightly-ApacheGeode > #1005 was successful. --- Scheduled 2425 tests in total. https://build.spring.io/browse/SGF-NAG-1005/ -- This message is automatically generated by Atlassian Bamboo
Re: Testing code in geode-junit and geode-dunit src/main
This looks great John! I'll spend some time going through all of this soon. Thanks! On Fri, Aug 10, 2018 at 10:04 AM, John Blum wrote: > If you haven't seen this, you should have a look at *Spring Test for Apache > Geode* (STDG) [1] > > I have much work to do yet to round this project out: docs, more > "formalized" integration test support (think JUnit Rules and custom Runners > over extension, etc) and so on. > > However, mocking for Geode Objects in Unit Tests is very robust and > complete. For instance, writing a Unit Test with mocked Geode Objects is > as simple as [2]. When using @EnableGemFireMockObjects annotation, you > literally get a mock object for every single Geode object: [Client]Cache, > CacheServer, Region, Index, DiskStore, AEQ, Gateway[Sender|Receiver], etc. > > Still, even the integration test support is pretty extensive, handling > things that the user would not normally know to handle. > > You can find many examples of this test framework in action in *Spring Boot > for Apache Geode* (SBDG) [3] as it was used extensively to test SBDG. Over > time, I plan to retrofit and consolidate *Spring Data for Apache Geode* > (SDG) and *Spring Session for Apache Geode's* (SSDG) test suites on this > test framework. > > Regards, > John > > > [1] https://github.com/spring-projects/spring-test-data-geode > [2] > https://github.com/spring-projects/spring-boot-data- > geode/blob/master/spring-geode/src/test/java/org/ > springframework/geode/config/annotation/DurableClientConfigurationInte > grationTests.java#L121-L124 > [3] https://github.com/spring-projects/spring-boot-data-geode > > > > On Fri, Aug 10, 2018 at 9:37 AM, Kirk Lund wrote: > > > In my opinion geode-junit and geode-dunit should be treated as testing > > frameworks that users can use to build better geode tests with. Think > JUnit > > or Mockito here. We have some valuable rules and dunit is valuable > > framework for more than building geode. We've been talking about > providing > > this to users for years. That's why I consider them to be more than just > > local tests within geode. I'm sorry if this doesn't match with your > > expectation but I assure that I've been working towards this goal for > years > > and I don't plan to give up on this goal. > > > > Now, here's another option for you: introduce yet another module > geode-test > > which is NOT published and is only used for tests local within the geode > > code base. > > > > I disagree with publishing non-framework code in either geode-junit or > > geode-dunit and I want to make these 100% useful and well-organized for > > users. I prefer to either duplicate code such as MyCacheListener across > the > > tests that need them or grouping them in a non-published geode-test > module. > > > > On Fri, Aug 10, 2018 at 8:36 AM, Jacob Barrett > > wrote: > > > > > I am not sure why you think geode-junit and geode-dunit are production > > jars > > > and should be treated as such. They are test framework jars in the same > > > vein as org.springframework:spring-test or > > > org.apache.lucene:lucene-test-framework. The should contain shared > class > > > for producing tests against the geode product. They could certainly use > > > some refinement. I would suggest we create a geode-test main module > with > > > sub modules for unit, integration, distributed and upgrade style test > > > frameworks. I would also create sub-modules for common test domain > > objects > > > that main not be as beneficial to the consumers downstream but are > shared > > > between primary modules in our projects. > > > > > > Thanks for finding the tests that were meant to test the framework. I > > have > > > refactored them into the appropriate test sources sets. > > > > > > More inline below: > > > > > > On Thu, Aug 9, 2018 at 3:56 PM Kirk Lund wrote: > > > > > > > Here are the tests that are no longer running because they've been > > moved > > > to > > > > src/main (was this reviewed?): > > > > > > > > /Users/klund/dev/gemfire/open/geode-dunit > > > [2294]$ > > > > find . -name '*Test.java' > > > > > > > > ./src/main/java/org/apache/geode/codeAnalysis/ > > > AnalyzeSerializablesJUnitTest.java > > > > > > > Has been split into a base class that all other projects derive from > and > > > moved to geode-junit. > > > > > > > > > > ./src/main/java/org/apache/geode/security/templates/ > > > PKCSPrincipalTest.java > > > > > > > > ./src/main/java/org/apache/geode/security/templates/ > > > UsernamePrincipalTest.java > > > > > > > Moved these unit tests to dunit/src/test > > > > > > > > > > > > > > ./src/main/java/org/apache/geode/test/dunit/cache/examples/ > > > CacheTestCaseExampleTest.java > > > > > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > > > AsyncInvokeCallableExampleTest.java > > > > > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > > > AsyncInvokeRunnableExampleTest.java > > > > > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > > > BeforeClassExampleTest.java
Re: Testing code in geode-junit and geode-dunit src/main
Sounds good! I'll be offline next week but available to join in on this or anything else after that. On Fri, Aug 10, 2018 at 12:14 PM, Jacob Barrett wrote: > I think we are on the same page but maybe disagree on some details. I’m > more than happy to go further in refactoring this testing mess into > additional modules. We can even have a more clear outline of what goes in > each test module. > > The current effort to fix inter project test dependencies is not going to > tackle that directly. This is an iterative approach to cleaning up things > that should never been allowed to happen in the first place. Be patient and > we will get to a good clean end state. > > -Jake > > > > On Aug 10, 2018, at 9:37 AM, Kirk Lund wrote: > > > > In my opinion geode-junit and geode-dunit should be treated as testing > > frameworks that users can use to build better geode tests with. Think > JUnit > > or Mockito here. We have some valuable rules and dunit is valuable > > framework for more than building geode. We've been talking about > providing > > this to users for years. That's why I consider them to be more than just > > local tests within geode. I'm sorry if this doesn't match with your > > expectation but I assure that I've been working towards this goal for > years > > and I don't plan to give up on this goal. > > > > Now, here's another option for you: introduce yet another module > geode-test > > which is NOT published and is only used for tests local within the geode > > code base. > > > > I disagree with publishing non-framework code in either geode-junit or > > geode-dunit and I want to make these 100% useful and well-organized for > > users. I prefer to either duplicate code such as MyCacheListener across > the > > tests that need them or grouping them in a non-published geode-test > module. > > > >> On Fri, Aug 10, 2018 at 8:36 AM, Jacob Barrett > wrote: > >> > >> I am not sure why you think geode-junit and geode-dunit are production > jars > >> and should be treated as such. They are test framework jars in the same > >> vein as org.springframework:spring-test or > >> org.apache.lucene:lucene-test-framework. The should contain shared > class > >> for producing tests against the geode product. They could certainly use > >> some refinement. I would suggest we create a geode-test main module with > >> sub modules for unit, integration, distributed and upgrade style test > >> frameworks. I would also create sub-modules for common test domain > objects > >> that main not be as beneficial to the consumers downstream but are > shared > >> between primary modules in our projects. > >> > >> Thanks for finding the tests that were meant to test the framework. I > have > >> refactored them into the appropriate test sources sets. > >> > >> More inline below: > >> > >>> On Thu, Aug 9, 2018 at 3:56 PM Kirk Lund wrote: > >>> > >>> Here are the tests that are no longer running because they've been > moved > >> to > >>> src/main (was this reviewed?): > >>> > >>> /Users/klund/dev/gemfire/open/geode-dunit > >> [2294]$ > >>> find . -name '*Test.java' > >>> > >>> ./src/main/java/org/apache/geode/codeAnalysis/ > >> AnalyzeSerializablesJUnitTest.java > >>> > >> Has been split into a base class that all other projects derive from and > >> moved to geode-junit. > >> > >> > >>> ./src/main/java/org/apache/geode/security/templates/ > >> PKCSPrincipalTest.java > >>> > >>> ./src/main/java/org/apache/geode/security/templates/ > >> UsernamePrincipalTest.java > >>> > >> Moved these unit tests to dunit/src/test > >> > >> > >>> > >>> ./src/main/java/org/apache/geode/test/dunit/cache/examples/ > >> CacheTestCaseExampleTest.java > >>> > >>> ./src/main/java/org/apache/geode/test/dunit/examples/ > >> AsyncInvokeCallableExampleTest.java > >>> > >>> ./src/main/java/org/apache/geode/test/dunit/examples/ > >> AsyncInvokeRunnableExampleTest.java > >>> > >>> ./src/main/java/org/apache/geode/test/dunit/examples/ > >> BeforeClassExampleTest.java > >>> > >>> ./src/main/java/org/apache/geode/test/dunit/examples/ > >> CatchingUnexpectedExceptionExampleTest.java > >>> > >>> ./src/main/java/org/apache/geode/test/dunit/examples/ > >> DistributedTestCaseExampleTest.java > >>> > >>> ./src/main/java/org/apache/geode/test/dunit/examples/ > >> DistributedTestRuleExampleTest.java > >>> > >>> ./src/main/java/org/apache/geode/test/dunit/examples/ > >> DoNotHandleUnexpectedExceptionExampleTest.java > >>> > >>> ./src/main/java/org/apache/geode/test/dunit/examples/ > >> FixtureOrderingExampleTest.java > >>> > >>> ./src/main/java/org/apache/geode/test/dunit/examples/ > >> InvokeRunnableExampleTest.java > >>> > >>> ./src/main/java/org/apache/geode/test/dunit/examples/ > >> LocatorPortClusterExampleTest.java > >>> > >>> ./src/main/java/org/apache/geode/test/dunit/examples/ > >> ReplaceTryFinallyExampleTest.java > >>> > >> All of these are "examples". I wonder if they should be treated > >> differently. For the time they are in geode-dunit/src/distributedTest. > >> >
Re: August 2018 Board Report Volunteer
Report has been posted. Thanks all! --Mark On Thu, Aug 9, 2018 at 4:40 PM Anthony Baker wrote: > @Mark, looks like we got enough eyeballs on this. Can you submit? > > Thanks, > Anthony > > > > On Aug 9, 2018, at 4:03 PM, Dave Barnes wrote: > > > > +1 LGTM > > > > On Thu, Aug 9, 2018 at 3:57 PM, Kirk Lund wrote: > > > >> +1 looks good! > >> > >> On Thu, Aug 9, 2018 at 3:46 PM, Anthony Baker > wrote: > >> > >>> This is a bit late so please review asap. Thanks! > >>> > >>> ## Description: > >>> Apache Geode provides a database-like consistency model, reliable > >>> transaction processing and a shared-nothing architecture to maintain > >>> very low latency performance with high concurrency processing. > >>> > >>> ## Issues: > >>> There are no issues requiring board attention at this time. > >>> > >>> ## Activity: > >>> - We held up releasing v1.7.0 in favor of fixing more bugs and making > >>> our tests more reliable. We closed out 40% of the open test bugs (out > >>> of 220) and removed the ‘FlakyTest’ category from 136 tests. > >>> - We integrated our pre-commit tests directly into GitHub PR checks. > >>> This makes it super easy for committers and contributors to run and > >>> review test results. > >>> - We’ve optimized test runtimes for pull requests to get results in > >>> less than an hour. If someone were to run the same tests on a laptop > >>> it would take over 18h. > >>> - We upgraded the project build tools to Gradle 4.9 in preparation for > >>> supporting Java 11. > >>> - We merged a contribution to add thread monitoring and take action if > >>> a thread appears to hang. > >>> - We discussed improvements to handling of the default SSL context. > >>> - We discussed improvements to allow customizable trust boundaries for > >>> securing OQL method invocations. > >>> - The Geode PMC discussed and approved a Geode session track at the > >>> SpringOnePlatform conference (see > >>> https://springoneplatform.io/2018/geode). > >>> - Community member Addison Huddy posted a series of seven (and > >>> counting) youtube videos on “Geode by Example”. > >>> > >>> ## Health report: > >>> - We’ve had a number of excellent contributions from new community > >>> members in the last three months. Although the PMC did not add any > >>> committers this quarter we should definitely review and discuss adding > >>> new committers soon. > >>> - By increasing test speed, reliability, and ease of access we have > >>> lowered the barriers for new contributions and community > >>> participation. > >>> > >>> ## PMC changes: > >>> > >>> - Currently 46 PMC members. > >>> - No new PMC members added in the last 3 months > >>> - Last PMC addition was Dick Cavender on Tue Feb 20 2018 > >>> > >>> ## Committer base changes: > >>> > >>> - Currently 87 committers. > >>> - No new committers added in the last 3 months > >>> - Last committer addition was Michael W. Dodge at Wed Jan 24 2018 > >>> > >>> ## Releases: > >>> > >>> - Last release was 1.6.0 on Fri May 04 2018 > >>> > >>> ## Mailing list activity: > >>> > >>> Mailing lists have remained active and have maintained consistent usage > >>> levels. > >>> > >>> - dev@geode.apache.org: > >>> - 183 subscribers (up 0 in the last 3 months): > >>> - 683 emails sent to list (793 in previous quarter) > >>> > >>> - iss...@geode.apache.org: > >>> - 54 subscribers (up 0 in the last 3 months): > >>> - 2991 emails sent to list (6890 in previous quarter) > >>> > >>> - u...@geode.apache.org: > >>> - 242 subscribers (down -9 in the last 3 months): > >>> - 141 emails sent to list (148 in previous quarter) > >>> > >>> ## JIRA activity: > >>> > >>> - 349 JIRA tickets created in the last 3 months > >>> - 330 JIRA tickets closed/resolved in the last 3 months > >>> > >>> Anthony > >>> > >>> On Thu, Jul 26, 2018 at 1:52 PM Dave Barnes > wrote: > > ...and just between you and me, if people knew how easy is to generate > >>> this > report using the template, they wouldn't be so reluctant to put forth > a > little effort on behalf of this great project :). Oh, did I say that > >> out > loud? > > On Thu, Jul 26, 2018 at 1:45 PM, Dave Barnes > >> wrote: > > > Hi Mark, > > Just between you and me, if nobody else steps up I'll be your safety > >>> net. > > Only tricky part is I'll be on PTO through 8/7. But if you don't have > > anybody by 8/8, I can jump in. > > Dave > > > > > > On Thu, Jul 26, 2018 at 12:22 PM, Mark Bretl > >>> wrote: > > > >> Hi Everyone, > >> > >> Its that time again to submit a report for the August Board Meeting. > >>> We > >> need to submit a report by August 8th. Would anyone like to > >> volunteer > >>> to > >> write a draft of the report? > >> > >> Template: https://cwiki.apache.org/confluence/display/GEODE/ASF+ > >>> Board+ > >> Report > >> +Template > >> > >> Previous Reports: https://whimsy.apache.org/ > >> board/minutes/Geode.html > >>
Re: Testing code in geode-junit and geode-dunit src/main
I think we are on the same page but maybe disagree on some details. I’m more than happy to go further in refactoring this testing mess into additional modules. We can even have a more clear outline of what goes in each test module. The current effort to fix inter project test dependencies is not going to tackle that directly. This is an iterative approach to cleaning up things that should never been allowed to happen in the first place. Be patient and we will get to a good clean end state. -Jake > On Aug 10, 2018, at 9:37 AM, Kirk Lund wrote: > > In my opinion geode-junit and geode-dunit should be treated as testing > frameworks that users can use to build better geode tests with. Think JUnit > or Mockito here. We have some valuable rules and dunit is valuable > framework for more than building geode. We've been talking about providing > this to users for years. That's why I consider them to be more than just > local tests within geode. I'm sorry if this doesn't match with your > expectation but I assure that I've been working towards this goal for years > and I don't plan to give up on this goal. > > Now, here's another option for you: introduce yet another module geode-test > which is NOT published and is only used for tests local within the geode > code base. > > I disagree with publishing non-framework code in either geode-junit or > geode-dunit and I want to make these 100% useful and well-organized for > users. I prefer to either duplicate code such as MyCacheListener across the > tests that need them or grouping them in a non-published geode-test module. > >> On Fri, Aug 10, 2018 at 8:36 AM, Jacob Barrett wrote: >> >> I am not sure why you think geode-junit and geode-dunit are production jars >> and should be treated as such. They are test framework jars in the same >> vein as org.springframework:spring-test or >> org.apache.lucene:lucene-test-framework. The should contain shared class >> for producing tests against the geode product. They could certainly use >> some refinement. I would suggest we create a geode-test main module with >> sub modules for unit, integration, distributed and upgrade style test >> frameworks. I would also create sub-modules for common test domain objects >> that main not be as beneficial to the consumers downstream but are shared >> between primary modules in our projects. >> >> Thanks for finding the tests that were meant to test the framework. I have >> refactored them into the appropriate test sources sets. >> >> More inline below: >> >>> On Thu, Aug 9, 2018 at 3:56 PM Kirk Lund wrote: >>> >>> Here are the tests that are no longer running because they've been moved >> to >>> src/main (was this reviewed?): >>> >>> /Users/klund/dev/gemfire/open/geode-dunit >> [2294]$ >>> find . -name '*Test.java' >>> >>> ./src/main/java/org/apache/geode/codeAnalysis/ >> AnalyzeSerializablesJUnitTest.java >>> >> Has been split into a base class that all other projects derive from and >> moved to geode-junit. >> >> >>> ./src/main/java/org/apache/geode/security/templates/ >> PKCSPrincipalTest.java >>> >>> ./src/main/java/org/apache/geode/security/templates/ >> UsernamePrincipalTest.java >>> >> Moved these unit tests to dunit/src/test >> >> >>> >>> ./src/main/java/org/apache/geode/test/dunit/cache/examples/ >> CacheTestCaseExampleTest.java >>> >>> ./src/main/java/org/apache/geode/test/dunit/examples/ >> AsyncInvokeCallableExampleTest.java >>> >>> ./src/main/java/org/apache/geode/test/dunit/examples/ >> AsyncInvokeRunnableExampleTest.java >>> >>> ./src/main/java/org/apache/geode/test/dunit/examples/ >> BeforeClassExampleTest.java >>> >>> ./src/main/java/org/apache/geode/test/dunit/examples/ >> CatchingUnexpectedExceptionExampleTest.java >>> >>> ./src/main/java/org/apache/geode/test/dunit/examples/ >> DistributedTestCaseExampleTest.java >>> >>> ./src/main/java/org/apache/geode/test/dunit/examples/ >> DistributedTestRuleExampleTest.java >>> >>> ./src/main/java/org/apache/geode/test/dunit/examples/ >> DoNotHandleUnexpectedExceptionExampleTest.java >>> >>> ./src/main/java/org/apache/geode/test/dunit/examples/ >> FixtureOrderingExampleTest.java >>> >>> ./src/main/java/org/apache/geode/test/dunit/examples/ >> InvokeRunnableExampleTest.java >>> >>> ./src/main/java/org/apache/geode/test/dunit/examples/ >> LocatorPortClusterExampleTest.java >>> >>> ./src/main/java/org/apache/geode/test/dunit/examples/ >> ReplaceTryFinallyExampleTest.java >>> >> All of these are "examples". I wonder if they should be treated >> differently. For the time they are in geode-dunit/src/distributedTest. >> >> >> ./src/main/java/org/apache/geode/test/dunit/internal/ >> DUnitBlackboardDUnitTest.java >>> >>> ./src/main/java/org/apache/geode/test/dunit/rules/tests/ >> CacheRuleBuilderDistributedTest.java >>> >>> ./src/main/java/org/apache/geode/test/dunit/rules/tests/ >> CacheRuleDistributedTest.java >>> >>> ./src/main/java/org/apache/geode/test/dunit/rules/tests/ >>
Re: Testing code in geode-junit and geode-dunit src/main
If you haven't seen this, you should have a look at *Spring Test for Apache Geode* (STDG) [1] I have much work to do yet to round this project out: docs, more "formalized" integration test support (think JUnit Rules and custom Runners over extension, etc) and so on. However, mocking for Geode Objects in Unit Tests is very robust and complete. For instance, writing a Unit Test with mocked Geode Objects is as simple as [2]. When using @EnableGemFireMockObjects annotation, you literally get a mock object for every single Geode object: [Client]Cache, CacheServer, Region, Index, DiskStore, AEQ, Gateway[Sender|Receiver], etc. Still, even the integration test support is pretty extensive, handling things that the user would not normally know to handle. You can find many examples of this test framework in action in *Spring Boot for Apache Geode* (SBDG) [3] as it was used extensively to test SBDG. Over time, I plan to retrofit and consolidate *Spring Data for Apache Geode* (SDG) and *Spring Session for Apache Geode's* (SSDG) test suites on this test framework. Regards, John [1] https://github.com/spring-projects/spring-test-data-geode [2] https://github.com/spring-projects/spring-boot-data-geode/blob/master/spring-geode/src/test/java/org/springframework/geode/config/annotation/DurableClientConfigurationIntegrationTests.java#L121-L124 [3] https://github.com/spring-projects/spring-boot-data-geode On Fri, Aug 10, 2018 at 9:37 AM, Kirk Lund wrote: > In my opinion geode-junit and geode-dunit should be treated as testing > frameworks that users can use to build better geode tests with. Think JUnit > or Mockito here. We have some valuable rules and dunit is valuable > framework for more than building geode. We've been talking about providing > this to users for years. That's why I consider them to be more than just > local tests within geode. I'm sorry if this doesn't match with your > expectation but I assure that I've been working towards this goal for years > and I don't plan to give up on this goal. > > Now, here's another option for you: introduce yet another module geode-test > which is NOT published and is only used for tests local within the geode > code base. > > I disagree with publishing non-framework code in either geode-junit or > geode-dunit and I want to make these 100% useful and well-organized for > users. I prefer to either duplicate code such as MyCacheListener across the > tests that need them or grouping them in a non-published geode-test module. > > On Fri, Aug 10, 2018 at 8:36 AM, Jacob Barrett > wrote: > > > I am not sure why you think geode-junit and geode-dunit are production > jars > > and should be treated as such. They are test framework jars in the same > > vein as org.springframework:spring-test or > > org.apache.lucene:lucene-test-framework. The should contain shared class > > for producing tests against the geode product. They could certainly use > > some refinement. I would suggest we create a geode-test main module with > > sub modules for unit, integration, distributed and upgrade style test > > frameworks. I would also create sub-modules for common test domain > objects > > that main not be as beneficial to the consumers downstream but are shared > > between primary modules in our projects. > > > > Thanks for finding the tests that were meant to test the framework. I > have > > refactored them into the appropriate test sources sets. > > > > More inline below: > > > > On Thu, Aug 9, 2018 at 3:56 PM Kirk Lund wrote: > > > > > Here are the tests that are no longer running because they've been > moved > > to > > > src/main (was this reviewed?): > > > > > > /Users/klund/dev/gemfire/open/geode-dunit > > [2294]$ > > > find . -name '*Test.java' > > > > > > ./src/main/java/org/apache/geode/codeAnalysis/ > > AnalyzeSerializablesJUnitTest.java > > > > > Has been split into a base class that all other projects derive from and > > moved to geode-junit. > > > > > > > ./src/main/java/org/apache/geode/security/templates/ > > PKCSPrincipalTest.java > > > > > > ./src/main/java/org/apache/geode/security/templates/ > > UsernamePrincipalTest.java > > > > > Moved these unit tests to dunit/src/test > > > > > > > > > > ./src/main/java/org/apache/geode/test/dunit/cache/examples/ > > CacheTestCaseExampleTest.java > > > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > > AsyncInvokeCallableExampleTest.java > > > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > > AsyncInvokeRunnableExampleTest.java > > > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > > BeforeClassExampleTest.java > > > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > > CatchingUnexpectedExceptionExampleTest.java > > > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > > DistributedTestCaseExampleTest.java > > > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > > DistributedTestRuleExampleTest.java > > > > > >
Re: Testing code in geode-junit and geode-dunit src/main
In my opinion geode-junit and geode-dunit should be treated as testing frameworks that users can use to build better geode tests with. Think JUnit or Mockito here. We have some valuable rules and dunit is valuable framework for more than building geode. We've been talking about providing this to users for years. That's why I consider them to be more than just local tests within geode. I'm sorry if this doesn't match with your expectation but I assure that I've been working towards this goal for years and I don't plan to give up on this goal. Now, here's another option for you: introduce yet another module geode-test which is NOT published and is only used for tests local within the geode code base. I disagree with publishing non-framework code in either geode-junit or geode-dunit and I want to make these 100% useful and well-organized for users. I prefer to either duplicate code such as MyCacheListener across the tests that need them or grouping them in a non-published geode-test module. On Fri, Aug 10, 2018 at 8:36 AM, Jacob Barrett wrote: > I am not sure why you think geode-junit and geode-dunit are production jars > and should be treated as such. They are test framework jars in the same > vein as org.springframework:spring-test or > org.apache.lucene:lucene-test-framework. The should contain shared class > for producing tests against the geode product. They could certainly use > some refinement. I would suggest we create a geode-test main module with > sub modules for unit, integration, distributed and upgrade style test > frameworks. I would also create sub-modules for common test domain objects > that main not be as beneficial to the consumers downstream but are shared > between primary modules in our projects. > > Thanks for finding the tests that were meant to test the framework. I have > refactored them into the appropriate test sources sets. > > More inline below: > > On Thu, Aug 9, 2018 at 3:56 PM Kirk Lund wrote: > > > Here are the tests that are no longer running because they've been moved > to > > src/main (was this reviewed?): > > > > /Users/klund/dev/gemfire/open/geode-dunit > [2294]$ > > find . -name '*Test.java' > > > > ./src/main/java/org/apache/geode/codeAnalysis/ > AnalyzeSerializablesJUnitTest.java > > > Has been split into a base class that all other projects derive from and > moved to geode-junit. > > > > ./src/main/java/org/apache/geode/security/templates/ > PKCSPrincipalTest.java > > > > ./src/main/java/org/apache/geode/security/templates/ > UsernamePrincipalTest.java > > > Moved these unit tests to dunit/src/test > > > > > > ./src/main/java/org/apache/geode/test/dunit/cache/examples/ > CacheTestCaseExampleTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > AsyncInvokeCallableExampleTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > AsyncInvokeRunnableExampleTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > BeforeClassExampleTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > CatchingUnexpectedExceptionExampleTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > DistributedTestCaseExampleTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > DistributedTestRuleExampleTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > DoNotHandleUnexpectedExceptionExampleTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > FixtureOrderingExampleTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > InvokeRunnableExampleTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > LocatorPortClusterExampleTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/examples/ > ReplaceTryFinallyExampleTest.java > > > All of these are "examples". I wonder if they should be treated > differently. For the time they are in geode-dunit/src/distributedTest. > > > ./src/main/java/org/apache/geode/test/dunit/internal/ > DUnitBlackboardDUnitTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/ > CacheRuleBuilderDistributedTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/ > CacheRuleDistributedTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/ > ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/ > DistributedRestoreSystemPropertiesDistributedTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/ > DistributedTestRuleDistributedTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/ > MemberStarterRuleAwaitDUnitTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/ > MemberStarterRuleAwaitIntegrationTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/ > MemberStarterRuleIntegrationTest.java > > > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/ > MemberStarterRuleTest.java > >
Re: Testing code in geode-junit and geode-dunit src/main
I am not sure why you think geode-junit and geode-dunit are production jars and should be treated as such. They are test framework jars in the same vein as org.springframework:spring-test or org.apache.lucene:lucene-test-framework. The should contain shared class for producing tests against the geode product. They could certainly use some refinement. I would suggest we create a geode-test main module with sub modules for unit, integration, distributed and upgrade style test frameworks. I would also create sub-modules for common test domain objects that main not be as beneficial to the consumers downstream but are shared between primary modules in our projects. Thanks for finding the tests that were meant to test the framework. I have refactored them into the appropriate test sources sets. More inline below: On Thu, Aug 9, 2018 at 3:56 PM Kirk Lund wrote: > Here are the tests that are no longer running because they've been moved to > src/main (was this reviewed?): > > /Users/klund/dev/gemfire/open/geode-dunit [2294]$ > find . -name '*Test.java' > > ./src/main/java/org/apache/geode/codeAnalysis/AnalyzeSerializablesJUnitTest.java > Has been split into a base class that all other projects derive from and moved to geode-junit. > ./src/main/java/org/apache/geode/security/templates/PKCSPrincipalTest.java > > ./src/main/java/org/apache/geode/security/templates/UsernamePrincipalTest.java > Moved these unit tests to dunit/src/test > > ./src/main/java/org/apache/geode/test/dunit/cache/examples/CacheTestCaseExampleTest.java > > ./src/main/java/org/apache/geode/test/dunit/examples/AsyncInvokeCallableExampleTest.java > > ./src/main/java/org/apache/geode/test/dunit/examples/AsyncInvokeRunnableExampleTest.java > > ./src/main/java/org/apache/geode/test/dunit/examples/BeforeClassExampleTest.java > > ./src/main/java/org/apache/geode/test/dunit/examples/CatchingUnexpectedExceptionExampleTest.java > > ./src/main/java/org/apache/geode/test/dunit/examples/DistributedTestCaseExampleTest.java > > ./src/main/java/org/apache/geode/test/dunit/examples/DistributedTestRuleExampleTest.java > > ./src/main/java/org/apache/geode/test/dunit/examples/DoNotHandleUnexpectedExceptionExampleTest.java > > ./src/main/java/org/apache/geode/test/dunit/examples/FixtureOrderingExampleTest.java > > ./src/main/java/org/apache/geode/test/dunit/examples/InvokeRunnableExampleTest.java > > ./src/main/java/org/apache/geode/test/dunit/examples/LocatorPortClusterExampleTest.java > > ./src/main/java/org/apache/geode/test/dunit/examples/ReplaceTryFinallyExampleTest.java > All of these are "examples". I wonder if they should be treated differently. For the time they are in geode-dunit/src/distributedTest. ./src/main/java/org/apache/geode/test/dunit/internal/DUnitBlackboardDUnitTest.java > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/CacheRuleBuilderDistributedTest.java > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/CacheRuleDistributedTest.java > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest.java > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/DistributedRestoreSystemPropertiesDistributedTest.java > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/DistributedTestRuleDistributedTest.java > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/MemberStarterRuleAwaitDUnitTest.java > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/MemberStarterRuleAwaitIntegrationTest.java > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/MemberStarterRuleIntegrationTest.java > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/MemberStarterRuleTest.java > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/SharedCountersRuleDistributedTest.java > > ./src/main/java/org/apache/geode/test/dunit/rules/tests/SharedErrorCollectorDistributedTest.java > ./src/main/java/org/apache/geode/test/dunit/tests/BasicDistributedTest.java > > ./src/main/java/org/apache/geode/test/dunit/tests/GetCurrentVmNumDistributedTest.java > ./src/main/java/org/apache/geode/test/dunit/tests/VMDistributedTest.java Moved to geode-dunit/src/distributedTest. > The following is the list of testing classes in geode-junit that probably > shouldn't be part of a geode-junit release: > > ./src/main/java/com/examples/ds/Address.java > ./src/main/java/com/examples/ds/Company.java > ./src/main/java/com/examples/ds/CompanySerializer.java > ./src/main/java/com/examples/ds/Employee.java > ./src/main/java/com/examples/ds/PutDataSerializables.java > ./src/main/java/com/examples/ds/User.java > ./src/main/java/com/examples/snapshot/MyDataSerializer.java > ./src/main/java/com/examples/snapshot/MyObject.java > ./src/main/java/com/examples/snapshot/MyObjectDataSerializable.java > ./src/main/java/com/examples/snapshot/MyObjectPdx.java > ./src/main/java/com/examples/snapshot/MyObjectPdxSerializable.java > ./src/main/java/com/examples/snapshot/MyPdxSerializer.java >
