[jira] [Updated] (GEODE-6512) Remove test-by-category.gradle

["Patrick Rhomberg (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Patrick Rhomberg updated GEODE-6512:
------------------------------------
    Description: 
This configuration macro is at best a violation of clean design and at worst an attractive pitfall for developers.

* The way configuration is injected into all subprojects violates each subproject's modularity.
* A known issue with JUnit4's category filtering means that every test is instantiated, regardless of category, and those not matching the given category is run as a no-op.  As a result, testing via category is very time intensive, even when running a trivial category with no tests in it.  This is what drove the redesign of tests to use Nebula {{facets}} and separate source sets, rather than our previous categories of {{UnitTest}}, {{IntegrationTest}}, et al.
* Because each target extends the Test task type, it only scans the {{test}} source set.  Developers may be mislead into thinking that all tests of the given category should be run under the given task.
* Also because each task is of the Test task type, it inherits only the {{UnitTest}} default configuration.  Even if the previous point were not true, we would expect many tests to fail due to invalid DUnit configuration.
* In fact, each type only inherits the default configuration, and not our correct JUnit configuration.  Tested locally with {{./gradlew securityTest}}, I see several initialization failures that result from improper configuration.

These categories are still useful to the developer for gathering tests within a given scope, e.g. {{SecurityTest}}, across our multiple testing facets, but as gradle targets, these are cruft that needs to be removed.

  was:
This configuration macro is at best a violation clean design and at worst an attractive pitfall for developers.

* The way configuration is injected into all subprojects violates each subproject's modularity.
* A known issue with JUnit4's category filtering means that every test is instantiated, regardless of category, and those not matching the given category is run as a no-op.  As a result, testing via category is very time intensive, even when running a trivial category with no tests in it.  This is what drove the redesign of tests to use Nebula {{facets}} and separate source sets, rather than our previous categories of {{UnitTest}}, {{IntegrationTest}}, et al.
* Because each target extends the Test task type, it only scans the {{test}} source set.  Developers may be mislead into thinking that all tests of the given category should be run under the given task.
* Also because each task is of the Test task type, it inherits only the {{UnitTest}} default configuration.  Even if the previous point were not true, we would expect many tests to fail due to invalid DUnit configuration.
* In fact, each type only inherits the default configuration, and not our correct JUnit configuration.  Tested locally with {{./gradlew securityTest}}, I see several initialization failures that result from improper configuration.

These categories are still useful to the developer for gathering tests within a given scope, e.g. {{SecurityTest}}, across our multiple testing facets, but as gradle targets, these are cruft that needs to be removed.


> Remove test-by-category.gradle
> ------------------------------
>
>                 Key: GEODE-6512
>                 URL: https://issues.apache.org/jira/browse/GEODE-6512
>             Project: Geode
>          Issue Type: Improvement
>            Reporter: Patrick Rhomberg
>            Priority: Major
>
> This configuration macro is at best a violation of clean design and at worst an attractive pitfall for developers.
> * The way configuration is injected into all subprojects violates each subproject's modularity.
> * A known issue with JUnit4's category filtering means that every test is instantiated, regardless of category, and those not matching the given category is run as a no-op.  As a result, testing via category is very time intensive, even when running a trivial category with no tests in it.  This is what drove the redesign of tests to use Nebula {{facets}} and separate source sets, rather than our previous categories of {{UnitTest}}, {{IntegrationTest}}, et al.
> * Because each target extends the Test task type, it only scans the {{test}} source set.  Developers may be mislead into thinking that all tests of the given category should be run under the given task.
> * Also because each task is of the Test task type, it inherits only the {{UnitTest}} default configuration.  Even if the previous point were not true, we would expect many tests to fail due to invalid DUnit configuration.
> * In fact, each type only inherits the default configuration, and not our correct JUnit configuration.  Tested locally with {{./gradlew securityTest}}, I see several initialization failures that result from improper configuration.
> These categories are still useful to the developer for gathering tests within a given scope, e.g. {{SecurityTest}}, across our multiple testing facets, but as gradle targets, these are cruft that needs to be removed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)