Environment Setup JDK, Ant and Junit: Case Study 3
Environment Setup JDK, Ant and Junit: Case Study 3
Environment Setup JDK, Ant and Junit: Case Study 3
Environment Setup
JDK, Ant and JUnit
3.1 Scenario
In this case study, we will get the bare-bones set of tools installed so we can begin
to develop, build, test, and deploy our Java code.
3.2 Objectives
In this case study, we begin the setup of our development environment with the
following core tools required for our Java development through the remainder of
this book:
Java Platform Standard Edition (JSE) Development Kit (JDK) setup
because this book is about Java technologies, this is the first software we
need to have working before we can do anything else.
Ant - This is the de facto utility for building and deploying Java-based
applications.
JUnit - This is a simple unit-testing framework and standard way of unit
testing Java code these days.
Make It All Work Together Finally, we will put together all three
technologies and try out a simple unit test.
..................................................................................................................
..................................................................................................................
<?xml version="1.0"?>
<project name="HelloTest" default="printmessage">
For example, if we saved this minimal XML code in a file named build.xml and
in the same directory type ant, the command and its output would look as
follows:
> ant
Buildfile: .......................................................
printmessage:
..................................................................
BUILD SUCCESSFUL
Total time: 0 seconds
Ant Concepts
Before we inspect our build.xml file step-by-step, let's review some basic
concepts about Ant. The key concepts in Ant include a project, properties, targets,
tasks, and elements.
Properties are .........................................................................................................
Targets contain ........................................................................................................
Tasks are ...................................................................................................................
Step-by-Step Walkthrough
Now, we will review the key targets in our build.xml file, but first, let's look at a
graphical representation of this file, shown in Figure 3.3. You may also want to
review Figure 3.1 one more time before we begin this walkthrough, because our
Ant build script is closely tied to this development directory structure.
The first XML element that must appear in an Ant file is .......................................,
as shown here:
The next few lines essentially set internal variables (properties) for our script.
Most of these properties are related to the various source and destination
directories we will use, as shown in this excerpt (notice how we can use internal
variables, surrounded by a dollar sign and braces; for example:
${dist.dir}):
<path id="master-classpath"
<fileset dir="${lib.dir}">
</fileset>
</path>
The next target in our build script, init, ensures that certain output directories
(under build/) are created in order for other tasks in our build script to be
successful (note, this is accomplished using the depends attribute in other
targets):
</target>
</target>
Our dist target creates a WAR file and deploys it to the pathname the internal
variable ${war.file} points to (that is, dist/timex.war). An interesting thing to
note about this target is the use of the war task and fileset element (known as an
Ant type). The war task creates a .war file; the fileset type can be used to specify
an individual file or a group of files (using include and exclude pattern sets).
Examples of both the war task and the fileset element are shown here:
<fileset dir="${war.dir}">
</war>
The other notable targets include deploy, clean, and test. The deploy target copies
the.war file to a destination directory (we will use it to deploy to an Apache
Tomcat webapps directory). The clean target deletes files from the destination
directory. We will use the test target later in the case study.
3.8 JUnit
JUnit, originally written by Erich Gamma (Gang of Four, Design Patterns book)
and Kent Beck (also author of Extreme Programming), is an open source Java
testing framework commonly used for unit testing of Java code. It can be
downloaded from the junit.org website; this website provides not only setup
instructions, but also articles on unit testing and many benefits to writing tests
first.
Test-driven development (TDD), a term coined by Kent Beck, can enable better
code design, cleaner code (fewer print/debug statements and test scripts), and
more efficient code. Because we will follow this approach by writing tests first in
this book, it makes sense to cover JUnit directly after JDK and Ant sections.
java .........................................................
SimpleTest.java
This book's code file (available on the book's website) shows the complete code
for SimpleTest.java. The code should be fairly straightforward to follow. There
are two test methods: testAddSuccess and testAddFail, as shown here:
public void testAddSuccess()
assertTrue(........................................);
assertTrue((........................................);); }
assertEquals
..............................
..............................
..............................
..............................
..............................
..............................
Now, let's try running our SimpleTest test case (from the top-level timex/
directory) using the JUnit test runner, as demonstrated here:
C:\anil\rapidjava\timex>java
-cp \junit3.8.1\junit.jar;build/timex/WEB-INF/classes
We could also run SimpleTest.class in the JUnit swing runner, as shown next
( Figure 3.8 shows the result of this command):
..................................................................
..................................................................
..................................................................
<classpath refid="master-classpath"/>
<batchtest fork="yes">
<formatter type="plain"/>
<fileset dir="${class.dir}">
FAILED
That's pretty much all there is to JUnit! Although JUnit is a simple framework, it
is powerful because you can have several test methods within each JUnit TestCase
subclass (a suite). Furthermore, you can roll up the individual suites within
other suites (with no limit). For example, you can create a class named AllTests,
which calls the suites of all other Test classes in the test package.
test/TimesheetManagerTest.java
test/ReminderEmailTest.java
I have chosen to keep our JUnit test classes in a separate test package (that is,
com.visualpatterns.timex.test) because I believe this is a cleaner design. However,
I've also seen other developers keep the JUnit test classes in the same directory as
the code being tested. For example, in this scenario, our
TimesheetListControllerTest.java would be placed in our controller
package.