geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Baker <aba...@pivotal.io>
Subject Re: DISCUSS: Refactor test source set for integrationTest and distributedTest
Date Tue, 26 Jun 2018 23:22:17 GMT
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 <dsmith@pivotal.io> wrote:
> 
> +1 for the suggested structure.
> 
> -Dan
> 
> On Tue, Jun 26, 2018 at 3:36 PM, Jacob Barrett <jbarrett@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
>> 


Mime
View raw message