I like the idea of good structure around our test-complexity @Category layout.
@Alexander, not to speak for Bruce, but to my mind things like SecurityTest / WanTest / etc are orthogonal to the UnitTest / IntegrationTest / DistributedTest / AcceptanceTest classification. I like adding better runtime and structure on the latter, but there's no real reason to sacrifice the former labeling. @Anthony, I'm pretty confident we'll need a commonTest. Off the top of my head, it'll need to host the startup rules, GfshRule, and the SimpleSecurityManager. On Tue, Jun 26, 2018 at 4:22 PM, Anthony Baker <aba...@pivotal.io> wrote: > Sounds good, though I’m not entirely sure we need ‘commonTest/‘. I guess > we’ll find out :-) > > Anthony > > > > On Jun 26, 2018, at 4:19 PM, Dan Smith <dsm...@pivotal.io> wrote: > > > > +1 for the suggested structure. > > > > -Dan > > > > On Tue, Jun 26, 2018 at 3:36 PM, Jacob Barrett <jbarr...@pivotal.io> > wrote: > > > >> I'd like to suggest that we refactor our current test source set, which > >> contains both unit, integration and distributed tests, into distinct > source > >> sets, test, integrationTest, distributedTest. These source sets would > >> replace the use of the primary categories UnitTest, IntegrationTest and > >> DistributedTest. > >> > >> The catalyst for this change is an issue that Gradle's test runner > doesn't > >> pre-filter categories when launching tests, so if the tests are > launched in > >> separate JVMs or Docker containers, like :distributeTest task, the cost > of > >> spinning up those resources is realized only to immediately exit without > >> running any test for all test classes in the module. Switching to > separate > >> source sets for each category would remove the need to filter on > category > >> and only tests in the corresponding source set would get executed in > their > >> external JVM or Docker container. An example of this issue is > >> geode-junit:distributedTest task, which forks all test classes in > separate > >> JVMs but never actually runs any tests since there are no > DistributedTest > >> tagged tests. > >> > >> The secondary effect is a way too isolate dependencies in each of the > >> source sets. Unit tests in the test set would not have dependencies need > >> for integration tests or distributed test so that if you accidentally > tried > >> to import classes from those frameworks you would get a compiler > failure. > >> Likewise, integration tests would not include distributed test framework > >> dependencies. Any shared test classes like mock, dummies, fakes, etc. > could > >> be shared in a commonTest source set, but would not contain any tests > >> itself. > >> > >> The proposed structure would look like this: > >> > >> test/ - only contains unit tests. > >> integrationTest/ - only contains integration style tests. > >> distributedTest/ - only includes DUnit based tests. > >> commonTest/ - includes commonly shared classes between each test > category. > >> Does not contain any classes. > >> > >> Thoughts? > >> > >> -Jake > >> > >
