Synoptic's ant test target improvements

[GoogleCodeExporter]

synoptic/build.xml defines a 'test' target that currently has a few issues:

1. The full path of the test class needs to be specified, even though all test 
classes in our project have unique names.

2. The 'junit.include' variable name that holds the test name and must be 
defined on the command line is obscure.

3. Running 'ant test' or 'ant -Djunit.include=blah test' results in BUILD 
SUCCESSFUL, even though both commands should fail.

The suggested improvements are:

1. Have the user supply a test class name without a path. Simply 
"VectorTimeTests" should suffice, since ant should be able to find the 
corresponding class file and its path.

2. Ideally, the variable would be eliminated from the user's view altogether. 
For example, the user can run 'ant test VectorTimeTests' and the last argument 
to ant would be interpreted as the test (or tests) to execute.

3. The target should fail if the specified test(s) cannot be found, or if the 
test(s) fails.

Original issue reported on code.google.com by bestchai on 25 Apr 2012 at 5:44

[GoogleCodeExporter]

In revision 2d2abe17f060.

Supports (mostly):

*  Regexes for file name, Full path names (starting with "synoptic"), mostly 
full paths names, etc (anything that would seem like it would match is 
(hopefully) matched.

*  Runs only files within Synoptic's test folder (anything under 
synoptic/bin/synoptic/tests).

*  Prints the name of all matching test files to be run.

Regexes for the file name aren't explicitly stated as being supported in the 
comments I wrote, but they'll work so long as the file name isn't '*' or 
something else that won't be parsed.  I would have added more, but conditional 
branching in ant is a bit haphazard.

Also, the only simple way for someone to set a parameter is with the 
-Dparametername=foo option, so unfortunately, I don't think I'll be able to 
implement 'ant test FooTest', and it'll have to stay as 'ant test 
-Djunit.include=FooTest' for now.

Finally, if a file name is not supplied correctly at all, or -Djunit.include is 
not set, then an error will be thrown accordingly.

The only thing I can think of that I haven't really implemented but might be 
able to later (I only really hacked this together in about an hour, so don't 
worry) is to catch/throw a simple exception rather than a stack trace if the 
regex supplied by the user is malformed, since the current implementation just 
injects it a larger regex.

Original comment by a.w.davi...@gmail.com on 25 Apr 2012 at 10:00

[GoogleCodeExporter]

Okay, this is already well done and will be useful! Fixed as of revision 
2d5da1bcddee

Original comment by bestchai on 25 Apr 2012 at 5:57

• Changed state: Fixed