Transcript 17 Slides - Monash University

Systems V & V, Quality
and Standards
Dr Sita Ramakrishnan
School CSSE
Monash University
© S Ramakrishnan
1
A day in the life of a Test Driven
Development (TDD) Practitioner
• Check out a module from the project’s src repository
• run all the unit tests on the repository to see if they pass
• Then, write new tests for the new use case (TDD)
(or write the code first & then the tests – non TDD)
• with new tests written first, compile/run will error as
no such use case is supported in the apps yet.
• write the relevant code to implement the use case &
show it is correct with a green bar in JUnit, then, you
can check in the code & the tests.
• must continually run the unit tests as part of the dev.
cycle for regression testing. Hence, tests should be
able to be run automatically.
© S Ramakrishnan
2
Automating JUnit and
Running Tests from Ant
• Consider problems that can arise during compilation in a large
project with mutiple classes with just tools such as a standard
javac compiler: no. of classes refer to each other, more classes need to be on
the classpath so complier can find them. In a build where mods to only some
classes, which classes to build? Which JUnit tests to run after each build?
• Developers
use Ant, Maven & Eclipse for building applications
and for automating JUnit tests.
• Running JUnit in command line mode is difficult for running
continuous tests in a project with a no. of classes.
• With lots of test & production classes in a project, error prone to
run entire set of regression tests by hand.
• Need an effective way to write & run tests.
© S Ramakrishnan
3
Automating JUnit
• Ant is a defacto standard tool for building Java apps & for
managing & automating JUnit tests. Ant is good for running JUnit
regression tests.
• Ant is a framework for running tools. Can use Ant to configure &
launch a Java compiler, for generating code, invoking JDBC queries
and for running JUnit test suites.
• Maven extends Ant and provides a wider project mgmt support.
• Most Java IDEs work with build tools like Ant & Maven.
• Many developers use IDE (e.g. Eclipse) to create & test code, and
then use Ant and Maven for distribution or deployment of the latest
version.
© S Ramakrishnan
4
Ant
• Apache’s Ant (http://ant.apache.org/) is an open-source Java based
build tool that lets you easily compile & test appl.
• Equivalent to unix “make”. Ant is based on XML scripts.
• Included in Eclipes & other Java IDEs.
• Ant is configured through a buildfile named build.xml by default.
• Can use Ant :
• to build the application to be tested;
• compile the JUnit test cases, run the JUnit test cases
• format the results
© S Ramakrishnan
5
Ant buildfile
• Manage the build process with Ant by creating a buildfile for
each of your projects.
• Project: a set of “targets” associated with a project – requires
default target to be specified, which is run, if no target is specified by
the user.
• Target: a specific function with a reference name, eg. compile, test
• may have dependencies e.g before running JUnit tests, appl. &
related JUnit tests must have compiled successfully
• buildfile can have several targets or entry points, and
encapsulates the various tasks required to create your apps &
required resources. You can run one task or chain a number of
tasks together.
© S Ramakrishnan
6
Ant buildfile
• Ant buildfile describes each task that you want to apply to a project.
• the task might be: compile src, generate Javadocs, query DB,
transfer or copy files, or run tests. A number of tasks come
bundled with Ant. You can also write your own tasks.
• Ant Tasks are:
• Compile: javac
• Execute: java, exec
• Archive: zip, unzip, jar, …
• Test: JUnit, JUnitReport
• File: copy, move, delete, mkdir, …
• Documentation: javadoc
• Other: property, antlr, xslt…
© S Ramakrishnan
7
Ant buildfile
• For reuse & easier configuration, you can define dynamic
property elements in an Ant buildfile.
• you can use property elements to set the parameters a
tool needs and a task to run the tool.
• to refer to a property in a buildfile, place the property
within a special notation: ${property}.
• So, you have in a buildfile: project, property elements,
targets & tasks
© S Ramakrishnan
8
Ant buildfile : Compile
The snippets of code used in these set of slides is from the textbook, JUnit in Action,
V Massol, Mannings Publ. 2004 available in the library.
Build.xml could have the Ant script shown below:
• compile all files under dir src with suffix *.java, and
put the .class files into the dir called bin
<project basedir=“.” name=“CSE4431” default=“compile”>
<property name=“src.dir” location=“${basedir}/src “ />
<property name=“bin.dir” location=“${basedir}/bin “ />
<target name=“compile”>
<javac fork=“yes” // set fork to yes to force Ant to use a separate JVM for each test
// good practice as it avoids interferences between test cases
srcdir=“${src.dir}” includes=“**/*.java”
destdir=“${bin.dir}”>
</javac>
</target>
</project>
© S Ramakrishnan
9
Ant buildfile : Compile targets
Compile targets that call the java compiler for a project XXX,
both for the production and the test code.
<project basedir=“.” name=“XXX” default=“test”>
<property file=“build.properties”/> // this file contains Ant properties that
// may be changed in the user’s system due to executing environment
// eg. Location of redistributable jars. Many open source projects
// provide a build.properties.sample you can copy & edit for use
<property name=“src.dir” location=“src”/> // define properties related
<property name=“src.java.dir” location=“${src.dir}/java” /> // to the
<property name=“src.test.dir” location=“${src.dir}/test” /> //source tree
<property name=“target.dir” location=“target”/> // define properties
<property name=“target.classes.java.dir”
// related
location=“${target.dir}/classes/java”/>
// to
<property name=“target.classes.test.dir”
// the
location=“${target.dir}/classes/test”/>
// output tree
…
© S Ramakrishnan
10
Compile targets that call the java compiler for a project XXX, both for
the production and the test code.
<target name=“compile.java”> // declare the target to compile the java
// production sources and name it compile.java
<mkdir dir=${target.classes.java.dir}”> // make sure dir exists for
// .class
<javac destdir=“${target.classes.java.dir}”/> // call java compiler &
// pass it destination dir to use
<src path=“${src.java.dir}”/> // tell java compiler which sources to compile
</javac>
</target>
<target name=“compile.test” depends=“compile.java”> // compile.test target has
// a dependency on compile.java target
<mkdir dir=${target.classes.test.dir}”>
<javac destdir=“${target.classes.test.dir}”/>
<src path=“${src.test.dir}”/>
<classpath> //add a nested classpath element to add the production classes
<pathelement location=“${target.classes.java.dir}”/> //you just
</classpath> // compiled to the classpath, as testclasses call prod.classes
</javac>
</target>
<target name=“compile” depends=“compile.java.compile.test”/> // create a compile
// target that automatically calls the compile.java & compile.test targets
© S Ramakrishnan
11
JUnit Task
Compile src & run test cases against the compiled classes as part of
the same build target:
<target name=“test” depends “compile”> // if Ant is asked to run the test target, Ant will run
// the compile target before running test
<junit printsummary=“yes” haltonerror=“yes” haltonfailure=“yes”
// printsummary attribute
// says render 1 line summary at the end of the test
// haltonfailure & haltonerror attributes say the build should stop if
// tests return a failure (one of the asserts did not pass) or
// an error (due to unexpected error)
fork=“yes” > //set fork to yes to force Ant to use a separate JVM for each test
<formatter type=“plain” usefile=“false”/> // configure junit task formatter to use
// plain text and output the test result to the console
<test name=“junitbook.sampling.TestDefaultController”/> // provide class name
// of the test you want to run
<classpath> //add a nested classpath element to add the production & test classes
<pathelement location=“${target.classes.java.dir}”/>
<pathelement location=“${target.classes.test.dir}”/>
</classpath>
</junit>
</target>
</project>
© S Ramakrishnan
12
Once the buildfile is ready, can run Ant from the command line like so:
c:\cse4431\stud-id-assignment1>ant
Buildfile: build.xml
compile.java:
[mkdir] created dir: c:\cse4431\stud-id-assignment1\target\classes\java
[javac] compiling xx source files to c:\cse4431\stud-id-assignment1\target\classes\java
compile.test:
[mkdir] created dir: c:\cse4431\stud-id-assignment1\target\classes\test
[javac] compiling yy source files to c:\cse4431\stud-id-assignment1\target\classes\test
compile:
test:
[mkdir] created dir: c:\cse4431\stud-id-assignment1\target\classes\report
[junit] Running the test …
[junit] Tests run: 2. Failures: 0. Errors: 0. Time elapsed: xx.xx sec
[junit] Testsuite: …class
[junit] Tests run: 2. Failures: 0. Errors: 0. Time elapsed: xx.xx sec
[junit] Testcase: testaa-1 took ab.cd sec
[junit] Testcase: testaa-2 took ac.bd sec
BUILD SUCCESSFUL
Total time: 10 seconds
C:\cse4431\stud-id-assignment1
© S Ramakrishnan
13
JUnit and Ant
• junit task is one of the components bundled in
Ant’s optional jar.
• optional jar file is for tasks that depend on another package, e.g JUnit
• Ant does not bundle a copy of JUnit. Make sure junit.jar
is in your system classpath or in the ANT_HOME/lib dir
• remember to update junit.jar in ANT_HOME/lib when installing a
new version of either Ant or JUnit.
© S Ramakrishnan
14
Pretty printing with JUnitReport
An optional Ant task, junitreport, is designed to output the results of the tests as XML.
Junitreport renders the XML into HTML using XSL stylesheet to produce a pretty printed report.
Changes shown in bold.
<project name=“sampling” default=“test”>
[…]
<property name=“target.report.dir”
location=“${target.dir}/report”/>
[…]
target name=“test” depends “compile”> // if Ant is asked to run the test target, Ant will run
// the compile target before running test
<mkdir dir=${target.report.dir}”/> // create the report dir
<junit printsummary=“yes” haltonerror=“yes” haltonfailure=“yes”
fork=“yes” >
<formatter type=“plain” usefile=“false”/>
<formatter type=“xml”/> // modify junit task so its output test results are in XML
<test name=“junitbook.sampling.TestDefaultController”/>
todir=“${target.report.dir}”/> // tell the junit task to create the report in this dir
<classpath> //add a nested classpath element to add the production & test classes
<pathelement location=“${target.classes.java.dir}”/>
<pathelement location=“${target.classes.test.dir}”/>
</classpath>
</junit>
</target>
contd next slide
© S Ramakrishnan
15
Pretty printing with JUnitReport
<target name=“report” depends =“test”> // create a new report target to generate html report
<mkdir dir=“${target.report.dir}/html”/> // create dir where html will be generated
<junitreport todir=“${target.report.dir}”> // call junitreport task to create the
report
<fileset dir=“${target.report.dir}”> //junitreport task works by scanning the list of
<include name=“TEST-*.xml”/> // XML test results you specify as an Ant fileset
</fileset>
<report todir=“${taret.report.dir}/html”/> // tell junitreport task where to
produce
// the HTML report
</junitreport>
</target>
</project>
© S Ramakrishnan
16
Batchtest element – Automatically finding the tests to run
• junit task has a batchtest element that lets you specify
testcases using wildcards.
Refer to JUnit in Action for more information
© S Ramakrishnan
17