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

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GEODE-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790934#comment-16790934 ] 

ASF subversion and git services commented on GEODE-6512:
--------------------------------------------------------

Commit 46641b42a801c99c6155e7ef12004610adc656bc in geode's branch refs/heads/develop from Patrick Rhomberg
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=46641b4 ]

GEODE-6512: Remove defunct test-by-category.


> 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
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> 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)