Bruce, what use case do you see for the category annotation going forward? Could we bring it back after we identified that we do in fact need it?
On Tue, Jun 26, 2018 at 4:13 PM, Bruce Schuchardt <bschucha...@pivotal.io> wrote: > This seems like a good idea to me. I've never liked having the different > types of tests all jumbled together. OTOH I like to be able to run all > MembershipTests using the category mechanism. I would like to keep that > ability, so I don't think we should do a wholesale removal of @Category. > You said "replace the use of primary categories", so I'm assuming you're > not suggesting we do that. > > > > On 6/26/18 3:36 PM, Jacob Barrett 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 >> >> >
