DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21387>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21387

[PATCH] Permit <junit> to turn on Java (1.4) assertions in tests + tested code

           Summary: [PATCH] Permit <junit> to turn on Java (1.4) assertions
                    in tests + tested code
           Product: Ant
           Version: 1.6Alpha (nightly)
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Optional Tasks
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


I like to sprinkle my library code with the 'assert' keyword to help ensure that
the internal state is consistent. A JUnit test will check that the external
contracts of everything behave as expected, but it would still be nice to do
these additional assertion checks just to make sure. Since assertions are off by
default in Java, <junit> will not normally permit the tested code to run its
assertions while being tested. This seems a shame - you want assertions turned
on aggressively while you are developing code, especially while you are testing 
it.

The attached patch adds an attribute 'javaassertions' to the <junit> task,
default false for compatibility (is that an issue?). If turned on, the whole
test runner gets assertions turned on in all packages. Practically, it is just
the tested code you care about (not e.g. the JUnit framework, or your unit tests
which are presumably using junit.framework.Assert in the normal way), but it
seems harmless to have it on for all packages anyway, and that is simplest.

For technical reasons, assertions can only be turned on (1) if you fork, (2) if
you use <classpath> when not forking. It seems odd to me to put testcases in the
Ant startup classpath, anyway (since you are normally compiling them from the
build script), so this is probably not a real limitation. Note that it is
assumed that if you are running JDK 1.4 and fork a VM, that JVM is also 1.4 and
can accept the -ea switch. If you try to turn on assertions and this is not
possible, a warning is printed.

Patch includes:

- code change with Javadoc
- manual addition
- WHATSNEW entry
- test case, of course :-)

The test case is only meaningful when run from JDK 1.4, otherwise it should just
pass without testing anything. (But please sanity-check this.)

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to