JUnit is a simple open source Java testing framework used to write and run repeatable automated tests. It is an instance of the xUnit architecture for unit testing framework.
Eclipse comes with JUnit built into the Workbench. Eclipse allows you to quickly create test case classes and test suite classes to write your test code in. With Eclipse, Test Driven Development (TDD), becomes very easy to organize and implement.
The class that you will want to test is created first so that Eclipse will be able to find that class under test when you build the test case class. The test cases are built with the needed imports and extensions for JUnit to run. Once the test case class is built the actual test cases are then coded in by the programmer.
The creation of test suites in Eclipse is even easier. When you create a test suite, Eclipse will name it for you and will specify all of the test cases in the scope of the project that it can find.
JUnit features include
• Assertions for testing expected results
• Test fixtures for sharing common test data
• Test suites for easily organizing and running tests
• Graphical and textual test runners
Reminder of JUnit Naming Conventions
Test Case Class: Named [classname]Test.java, where classname is the name of the class that is being tested.
Test Case Method: Named test[methodname], where methodname is the name of the method that is tested.
Test Suite: Default name for Eclipse is AllTests.java
It is considered a best practice in testing, to separate the test case code from the application code. It is also a good idea to separate your JUnit and FIT tests as well. Here is an example file structure that helps with this:
Assertion statements
This is a list of the different types of assertion statements that are used to test your code. Any Java data type or object can be used in the statement. These assertions are taken from the JUnit API.
assertEquals(expected, actual)
assertEquals(message, expected, actual)
assertEquals(expected, actual, delta) - used on doubles or floats, where delta is the difference in precision
assertEquals(message, expected, actual, delta) - used on doubles or floats, where delta is the difference in precision
assertFalse(condition)
assertFalse(message, condition)
assertNotNull(object)
assertNotNull(message, object)
assertNotSame(expected, actual)
assertNotSame(message, expected, actual)
assertNull(object)
assertNull(message, object)
assertSame(expected, actual)
assertSame(message, expected, actual)
assertTrue(condition)
assertTrue(message, condition)
fail()
fail(message)
failNotEquals(message, expected, actual)
failNotSame(message, expected, actual)
failSame(message)
TestRunner is the Java program that will systematically run each of the testMethods that you wrote in your TestXxxxx class. It will also automatically track and report the successes and failures recorded. The console version is good, but the graphic versions allow you to see a GREEN BAR when all tests pass. If any test fails, you will see a RED BAR instead. This visual information regarding the successes and failures of your implementation is not only useful, it is great fun to see.
Each of these commands assumes that you are in the parent directory of the application.
Console Window
java -classpath ".;c:\junit3.8.1\junit.jar" junit.textui.TestRunner junit.sample.AllTests
AWT GUI Frame
java -classpath ".;c:\junit3.8.1\junit.jar" junit.awtui.TestRunner junit.sample.AllTests
Swing GUI Frame
java -classpath ".;c:\junit3.8.1\junit.jar" junit.swingui.TestRunner junit.sample.AllTests
Struts is a framework that promotes the use of the Model-View-Controller architecture for designing large scale applications. The framework includes a set of custom tag libraries and their associated Java classes, along with various utility classes. The most powerful aspect of the Struts framework is its support for creating and processing web-based forms.
Model-View-Controller" is a way to build applications that promotes complete separation between business logic and presentation. It is not specific to web applications, or Java, or J2EE (it predates all of these by many years), but it can be applied to building J2EE web applications.
Diagram for Struts Workflow
StrutsTestCase for JUnit is an extension of the standard JUnit TestCase class that provides facilities for testing code based on the Struts framework. StrutsTestCase provides both a Mock Object approach and a Cactus approach to actually run the Struts ActionServlet, allowing you to test your Struts code with or without a running servlet engine. Because StrutsTestCase uses the ActionServlet controller to test your code, you can test not only the implementation of your Action objects, but also your mappings, form beans, and forwards declarations. And because StrutsTestCase already provides validation methods, it's quick and easy to write unit test cases.
There are two popular approaches to testing server-side classes: mock objects, which test classes by simulating the server container, and in-container testing, which tests classes running in the actual server container. StrutsTestCase for JUnit allows you to use either approach, with very minimal impact on your actual unit test code. In fact, because the StrutsTestCase setup and validation methods are exactly the same for both approaches, choosing one approach over the other simply effects which base class you use!
StrutsTestCase for JUnit provides two base classes, both of which are extensions of the standard JUnit TestCase. MockStrutsTestCase uses a set of HttpServlet mock objects to simulate the container environment without requiring a running servlet engine. CactusStrutsTestCase uses the Cactus testing framework to test Struts classes in the actual server container, allowing for a testing environment more in line with the actual deployment environment.
Note: While the following examples use the MockStrutsTestCase approach, you could choose to use the Cactus approach by simply subclassing from CactusStrutsTestCase without changing another line of code.