java left logo
java middle logo
java right logo
 

Home arrow Other API Tips arrow Ant arrow How to use JUnit task
 
 
Main Menu
Home
Java Tutorials
Book Reviews
Java SE Tips
Java ME Tips
Java EE Tips
Other API Tips
Java Applications
Java Libraries
Java Games
Java Network
Java Forums
Java Blog




Most Visited Tips
Java SE Tips
Java ME Tips
Java EE Tips
Other API Tips
Java Applications
Java Libraries
Java Games
Book Reviews
Top Rated Tips
Java SE Tips
Java ME Tips
Java EE Tips
Other API Tips
Java Applications
Java Libraries
Java Games
Book Reviews


Statistics
Registered Users: 4084
Java SE Tips: 614
Java ME Tips: 202
Java EE Tips: 183
Other API Tips: 779
Java Applications: 298
Java Libraries: 209
Java Games: 16
Book Reviews:
 
 
 
How to use JUnit task E-mail
User Rating: / 23
PoorBest 

JUnit

Description

This task runs tests from the JUnit testing framework. The latest version of the framework can be found at http://www.junit.org. This task has been tested with JUnit 3.0 up to JUnit 3.8.1; it won't work with versions prior to JUnit 3.0.

Note: This task depends on external libraries not included in the Ant distribution. See Library Dependencies for more information.

Note: You must have junit.jar and the class files for the <junit> task in the same classpath. You can do one of:

  1. Put both junit.jar and the optional tasks jar file in ANT_HOME/lib.
  2. Do not put either in ANT_HOME/lib, and instead include their locations in your CLASSPATH environment variable.
  3. Do neither of the above, and instead, specify their locations using a <classpath> element in the build file. See the FAQ for details.

Tests are defined by nested test or batchtest tags (see nested elements).

Parameters

Attribute Description Required
printsummary Print one-line statistics for each testcase. Can take the values on, off, and withOutAndErr. withOutAndErr is the same as on but also includes the output of the test as written to System.out and System.err. No; default is off.
fork Run the tests in a separate VM. No; default is off.
forkmode Controls how many Java Virtual Machines get created if you want to fork some tests. Possible values are "perTest" (the default), "perBatch" and "once". "once" creates only a single Java VM for all tests while "perTest" creates a new VM for each TestCase class. "perBatch" creates a VM for each nested <batchtest> and one collecting all nested <test>s. Note that only tests with the same settings of filtertrace, haltonerror, haltonfailure, errorproperty and failureproperty can share a VM, so even if you set forkmode to "once", Ant may have to create more than a single Java VM. This attribute is ignored for tests that don't get forked into a new Java VM. since Ant 1.6.2 No; default is perTest.
haltonerror Stop the build process if an error occurs during the test run. No; default is off.
errorproperty The name of a property to set in the event of an error. No
haltonfailure Stop the build process if a test fails (errors are considered failures as well). No; default is off.
failureproperty The name of a property to set in the event of a failure (errors are considered failures as well). No.
filtertrace Filter out Junit and Ant stack frames from error and failure stack traces. No; default is on.
timeout Cancel the individual tests if they don't finish in the given time (measured in milliseconds). Ignored if fork is disabled. No
maxmemory Maximum amount of memory to allocate to the forked VM. Ignored if fork is disabled. No
jvm The command used to invoke the Java Virtual Machine, default is 'java'. The command is resolved by java.lang.Runtime.exec(). Ignored if fork is disabled. No; default is java.
dir The directory in which to invoke the VM. Ignored if fork is disabled. No
newenvironment Do not propagate the old environment when new environment variables are specified. Ignored if fork is disabled. No; default is false.
includeantruntime Implicitly add the Ant classes required to run the tests and JUnit to the classpath in forked mode. Note: Please read the Ant FAQ if you want to set this to false and use the XML formatter at the same time. No; default is true.
showoutput Send any output generated by tests to Ant's logging system as well as to the formatters. By default only the formatters receive the output. No
tempdir Where Ant should place temporary files. Since Ant 1.6. No; default is the project's base directory.
reloading Whether or not a new classloader should be instantiated for each test case.
Ignore if fork is set to true. Since Ant 1.6.
No; default is true.

By using the errorproperty and failureproperty attributes, it is possible to perform setup work (such as starting an external server), execute the test, clean up, and still fail the build in the event of a failure.

The filtertrace attribute condenses error and failure stack traces before reporting them. It works with both the plain and XML formatters. It filters out any lines that begin with the following string patterns:

   "junit.framework.TestCase"
   "junit.framework.TestResult"
   "junit.framework.TestSuite"
   "junit.framework.Assert."
   "junit.swingui.TestRunner"
   "junit.awtui.TestRunner"
   "junit.textui.TestRunner"
   "java.lang.reflect.Method.invoke("
   "sun.reflect."
   "org.apache.tools.ant."

Nested Elements

The <junit> task supports a nested <classpath> element that represents a PATH like structure.

jvmarg

If fork is enabled, additional parameters may be passed to the new VM via nested <jvmarg> elements. For example:

<junit fork="yes">
  <jvmarg value="-Djava.compiler=NONE"/>

  ...
</junit>

would run the test in a VM without JIT.

<jvmarg> allows all attributes described in Command-line Arguments.

sysproperty

Use nested <sysproperty> elements to specify system properties required by the class. These properties will be made available to the VM during the execution of the test (either ANT's VM or the forked VM, if fork is enabled). The attributes for this element are the same as for environment variables.

<junit fork="no">
  <sysproperty key="basedir" value="${basedir}"/>

  ...
</junit>

would run the test in ANT's VM and make the basedir property available to the test.

syspropertyset

You can specify a set of properties to be used as system properties with syspropertysets.

since Ant 1.6.

env

It is possible to specify environment variables to pass to the forked VM via nested <env> elements. For a description of the <env> element's attributes, see the description in the exec task.

Settings will be ignored if fork is disabled.

bootclasspath

The location of bootstrap class files can be specified using this PATH like structure - will be ignored if fork is not true or the target VM doesn't support it (i.e. Java 1.1).

since Ant 1.6.

permissions

Security permissions can be revoked and granted during the execution of the class via a nested permissions element. For more information please see permissions

Settings will be ignored if fork is enabled.

since Ant 1.6.

assertions

You can control enablement of Java 1.4 assertions with an <assertions> subelement.

Assertion statements are currently ignored in non-forked mode.

since Ant 1.6.

formatter

The results of the tests can be printed in different formats. Output will always be sent to a file, unless you set the usefile attribute to false. The name of the file is determined by the name of the test and can be set by the outfile attribute of <test>.

There are three predefined formatters - one prints the test results in XML format, the other emits plain text. The formatter named brief will only print detailed information for testcases that failed, while plain gives a little statistics line for all test cases. Custom formatters that need to implement org.apache.tools.ant.taskdefs.optional.junit.JUnitResultFormatter can be specified.

If you use the XML formatter, it may not include the same output that your tests have written as some characters are illegal in XML documents and will be dropped.

Note: Please read the Ant FAQ if you want to set the fork attribute to true, the includeAntRuntime attribute to false and use the XML formatter at the same time.

Attribute Description Required
type Use a predefined formatter (either xml, plain, or brief). Exactly one of these.
classname Name of a custom formatter class.
extension Extension to append to the output filename. Yes, if classname has been used.
usefile Boolean that determines whether output should be sent to a file. No; default is true.
if Only use formatter if the named property is set. No; default is true.
unless Only use formatter if the named property is not set. No; default is true.

test

Defines a single test class.

Attribute Description Required
name Name of the test class. Yes
fork Run the tests in a separate VM. Overrides value set in <junit>. No
haltonerror Stop the build process if an error occurs during the test run. Overrides value set in <junit>. No
errorproperty The name of a property to set in the event of an error. Overrides value set in <junit>. No
haltonfailure Stop the build process if a test fails (errors are considered failures as well). Overrides value set in <junit>. No
failureproperty The name of a property to set in the event of a failure (errors are considered failures as well). Overrides value set in <junit>. No
filtertrace Filter out Junit and Ant stack frames from error and failure stack traces. Overrides value set in <junit>. No; default is on.
todir Directory to write the reports to. No; default is the current directory.
outfile Base name of the test result. The full filename is determined by this attribute and the extension of formatter. No; default is TEST-name, where name is the name of the test specified in the name attribute.
if Only run test if the named property is set. No
unless Only run test if the named property is not set. No

Tests can define their own formatters via nested <formatter> elements.

batchtest

Define a number of tests based on pattern matching.

batchtest collects the included files from any number of nested <fileset>s. It then generates a test class name for each file that ends in .java or .class.

Attribute Description Required
fork Run the tests in a separate VM. Overrides value set in <junit>. No
haltonerror Stop the build process if an error occurs during the test run. Overrides value set in <junit>. No
errorproperty The name of a property to set in the event of an error. Overrides value set in <junit>. No
haltonfailure Stop the build process if a test fails (errors are considered failures as well). Overrides value set in <junit>. No
failureproperty The name of a property to set in the event of a failure (errors are considered failures as well). Overrides value set in <junit> No
filtertrace Filter out Junit and Ant stack frames from error and failure stack traces. Overrides value set in <junit>. No; default is on.
todir Directory to write the reports to. No; default is the current directory.
if Only run tests if the named property is set. No
unless Only run tests if the named property is not set. No

Batchtests can define their own formatters via nested <formatter> elements.

Examples

<junit>
  <test name="my.test.TestCase"/>
</junit>

Runs the test defined in my.test.TestCase in the same VM. No output will be generated unless the test fails.

<junit printsummary="yes" fork="yes" haltonfailure="yes">
  <formatter type="plain"/>
  <test name="my.test.TestCase"/>
</junit>

Runs the test defined in my.test.TestCase in a separate VM. At the end of the test, a one-line summary will be printed. A detailed report of the test can be found in TEST-my.test.TestCase.txt. The build process will be stopped if the test fails.

<junit printsummary="yes" haltonfailure="yes">
  <classpath>
    <pathelement location="${build.tests}"/>

    <pathelement path="${java.class.path}"/>
  </classpath>

  <formatter type="plain"/>

  <test name="my.test.TestCase" haltonfailure="no" outfile="result">
    <formatter type="xml"/>

  </test>

  <batchtest fork="yes" todir="${reports.tests}">
    <fileset dir="${src.tests}">
      <include name="**/*Test*.java"/>
      <exclude name="**/AllTests.java"/>
    </fileset>

  </batchtest>
</junit>

Runs my.test.TestCase in the same VM, ignoring the given CLASSPATH; only a warning is printed if this test fails. In addition to the plain text test results, for this test a XML result will be output to result.xml. Then, for each matching file in the directory defined for ${src.tests} a test is run in a separate VM. If a test fails, the build process is aborted. Results are collected in files named TEST-name.txt and written to ${reports.tests}.

Source: Apache Ant


 Related Tips

 
< Prev   Next >

Page 1 of 0 ( 0 comments )

You can share your information about this topic using the form below!

Please do not post your questions with this form! Thanks.


Name (required)


E-Mail (required)

Your email will not be displayed on the site - only to our administrator
Homepage(optional)



Comment Enable HTML code : Yes No



 
       
         
     
 
 
 
   
 
 
java bottom left
java bottom middle
java bottom right
RSS 0.91 FeedRSS 1.0 FeedRSS 2.0 FeedATOM FeedOPML Feed

Home - About Us - Privacy Policy
Copyright 2005 - 2008 www.java-tips.org
Java is a trademark of Sun Microsystems, Inc.