@Patrick Those all sound like great use cases to me +1 to new structure. So far this seems like a change with no downsides.
On Tue, Jun 26, 2018 at 4:46 PM, Anilkumar Gingade <aging...@pivotal.io> wrote: > +1 for restructuring. > > -Anil. > > On Tue, Jun 26, 2018 at 4:34 PM, Patrick Rhomberg <prhomb...@pivotal.io> > wrote: > > > 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 > > > >> > > > > > > > > >
