[
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289558#comment-289558
]
John Casey edited comment on SUREFIRE-809 at 1/24/12 1:36 PM:
--------------------------------------------------------------
Applied in revIds: 1235412-1235416
All existing tests are passing; now I need to add a few new tests to verify the
extra expression combination features.
BTW, the mechanisms used to introduce these matchers into JUnit and TestNG are:
*JUnit:*
Modified FilterFactory to parse the group expressions, combine them into a
single matcher object (with the excludes matcher section inverted). Then,
wrapped the matcher in a JUnit Filter implementation, and passed back in place
of the old comma-separated listing of Filter instances.
*TestNG:*
Modified AbstractDirectConfigurator to parse group expressions in much the same
way as above (with JUnit), then set the matcher instance STATICALLY on a new
IMethodSelector implementation. This static setter is my workaround for the
fact that TestNG classloads / instantiates method selectors, rather than
allowing instances to be injected directly. I didn't want to use a file-based
approach, in case multiple TestNG processes ran simultaneously in a build (the
selector would have to know the file name). The old groups / excludeGroups
settings are commented out in favor of the new method selector.
These implementations may be controversial / flawed. If so, please provide some
guidance as to a preferred alternative mechanism, since I'm relatively
unfamiliar with the deep workings of these test frameworks.
was (Author: jdcasey):
Applied in revIds: 1235412-1235416
All existing tests are passing; now I need to add a few new tests to verify the
extra expression combination features.
BTW, the mechanisms used to introduce these matchers into JUnit and TestNG are:
JUnit: Modified FilterFactory to parse the group expressions, combine them into
a single matcher object (with the excludes matcher section inverted). Then,
wrapped the matcher in a JUnit Filter implementation, and passed back in place
of the old comma-separated listing of Filter instances.
TestNG: Modified AbstractDirectConfigurator to parse group expressions in much
the same way as above (with JUnit), then set the matcher instance STATICALLY on
a new IMethodSelector implementation. This static setter is my workaround for
the fact that TestNG classloads / instantiates method selectors, rather than
allowing instances to be injected directly. I didn't want to use a file-based
approach, in case multiple TestNG processes ran simultaneously in a build (the
selector would have to know the file name). The old groups / excludeGroups
settings are commented out in favor of the new method selector.
These implementations may be controversial / flawed. If so, please provide some
guidance as to a preferred alternative mechanism, since I'm relatively
unfamiliar with the deep workings of these test frameworks.
> Implement boolean expression to define test group to be run.
> ------------------------------------------------------------
>
> Key: SUREFIRE-809
> URL: https://jira.codehaus.org/browse/SUREFIRE-809
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Junit 4.x support
> Affects Versions: 2.11
> Reporter: Ondrej Zizka
> Attachments: BooleanExpression.g, category-expression.jj
>
>
> This is an alternative to SUREFIRE-808.
> Instead of having hard-coded filtering structure combining two lists.
> an expression could be parsed and evaluated for each test.
> Each test would be "tagged" using
> {code}
> @Categories({ MyCateg1.class, MyCateg2.class, ... })
> {code}
> Surefire's `group` config param would be an expression like:
> {code}
> <groups>( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )<groups>
> {code}
> Presence of a category of given name would be evaluated as true, absence of
> it as false.
> Interface inheritance would be taken into account.
> This mechanism would provide unlimited possibilities of grouping tests, and
> would be very beneficial for huge testuites counting thousands of tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
