Implement boolean expression to define test group to be run.

For parsing and evaluation, JEXL library could be used - http://commons.apache.org/jexl/ .
Other approach is to use ANTLR grammar, parse the expression and code the evaluation. Example of grammar is attached.
Also, there's older 2.x release of JEP library which was under GPL: http://sourceforge.net/projects/jep/

Anyone implementing this should note that it will be running on the fork-side, which means that we have to shade any external dependency. It's also a clear advantage to keep the dependency profile lean, since it affects fork startup-time - which is extremely lean in its current state.

I've (approximately) rewritten the attached grammar so it'll work with javacc, and created a series of matcher classes that will help me evaluate a category statement. I'm currently working on integrating this work into the junit and testng providers. The advantage of javacc here is that it generates a self-contained set classes, so we're not adding any new dependencies.

I haven't committed the grammar to trunk yet, so I'll attach it here. It's my first javacc grammar, so it could use some peer review!

javacc grammar for parsing category statements.

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.

I think the filter approach sounds excellent, at least for the JUnit part. I don't really know about the testng details

Oops. Sorry about running the release here. Let me know if it needs to be cancelled Or maybe this should be in the release notes

In revId 1235805:

Just added tests to verify the grouping expressions work both in JUnit and TestNG. The implementation for TestNG offends my design sensibilities, but I didn't have many options for injecting the group-expression matcher logic.

In the end, I had to split out the group-expression support into a separate module, and handle it much the same way the testng-utils artifact is handled...injected directly into the test classpath for testng tests. There was a tad more fine tuning related to the new integration tests too, but it's pretty minor.

This feature should be complete now.

Ready to go into the next release attempt for 2.12.

Hi John, could you please add a link to docs and/or the test cases? Thx.