java hosting


JavaRanch Newsletter Articles in this issue :
JUnitMatthew Phillips Printable Version
XML@Whiz Software ReviewValentin Crettaz Printable Version
Book Review of the MonthCindy Glass
Madhav Lakkapragada
Printable Version

JUnit

by Matthew Phillips

What is JUnit?

JUnit is a unit-testing framework. Unit-testing is a means of verifying the results you expect from your classes. Why perform unit testing? It leads to better code. If you write your test before hand and focus your code on passing the test you are more likely to end up with simple code that does what it should and nothing more. Unit-testing also assists in the refactoring process. If your code passes the unit-test after refactoring you will know that you haven't introduced any bugs to it.

Installing JUnit

JUnit makes unit-testing very easy to do. First you need to download JUnit from JUnit.org. Unzip the file and add the included junit.jar to your classpath. JUnit includes three TestRunners based on your user interface needs: a text based user interface, an AWT based user interface, and a Swing based user interface. I will briefly introduce each and then use the swing interface for the rest of the tutorial.

A simple implementation

The following is the code for our simple test case:


import junit.framework.* ;

public class LineItemTest extends TestCase {
    protected LineItem item ;
    
    public void setUp() {
        item = new LineItem( "Book" , 50.00 );
        System.out.println( "Line item setup" );
    }
    
    
    public void tearDown() {
        item = null ;
        System.out.println( "Line item teardown" );
    }
    
    
    public void testGetMethods() {
        System.out.println( "test get methods" );
        assertEquals( "Book" , item.getProduct() );
        assertTrue( 50.00 == item.getPrice() );
    }
    
    public void testBlank() {
        System.out.println( "this is a blank test" );
    }
}

Unit-tests are implemented as methods contained within one or more test classes. All test classes extend the TestCase class in the junit.framework package. I have included the System.out.println calls to show the general flow that the TestRunner takes. The setUp() and tearDown() methods are used to run code that is common to all test methods. They are called for each test method invoked by the test runner. The setUp() method will be called by the test runner before each test method. The tearDown() will be called after each test method. You may call your test methods anything you like, but if you start their name with test you will not have to override any other methods for the TestRunner to find them. The testGetMethods() contains two method calls. The assertEquals() method has two parameters: our expected results of the getProduct() method and a call to the getProduct method of LineItem. It will then test their equality based on the equals method in the class passed to it. The assertTrue() method checks the boolean passed to it. If either of these methods fail they will throw an AssertionFailedError which the TestRunner will catch and display. I included a testBlank() method so that the TestRunner will operate on two tests. One thing to keep in mind for versions of JUnit prior to 3.8 is that you will also be required to add a construtor that takes a String parameter and calls the parent classes constructor with that parameter. A public, no parameter constructor was added to the TestCase class in 3.8 thus eliminating the need to implement a constructor. The code for the LineItem class:


public class LineItem {
    private String product ;
    private double price ;
    
    public LineItem( String product , double price ) {
        this.product = product ;
        this.price = price ;
    }
    
    
    public String getProduct() {
        return product ;
    }
    
    
    public double getPrice() {
        return price ;
    }
}

Compile both of these. To run the text based test runner type the following command at a command prompt:

java junit.textui.TestRunner LineItemTest

You should receive the results of the println calls and an OK message with the time the test took to run. JUnit doesn't bother with a lot of messages telling you a test passed. It only delivers the messages when the tests fail. The command for the AWT user interface is java junit.awtui.TestRunner. The Swing based interface command is java junit.swinui.TestRunner.

Implementing your own test

Writing your own test case is simple. We will extend on our LineItem example by implementing a sales order. Our test case will test the sales order's ability to return a total. The test case will look like this:


import junit.framework.* ;

public class SalesOrderTest extends TestCase {
    protected LineItem item1 ;
    protected LineItem item2 ;
    protected SalesOrder order ;
    
    public void setUp() {
        item1 = new LineItem( "Book" , 50.00 );
        item2 = new LineItem( "Tape" , 10.00 );
        order = new SalesOrder();
        order.add( item1 );
        order.add( item2 );
    }
    
    
    public void tearDown() {
        item1 = null ;
        item2 = null ;
        order = null ;
    }


    public void testTotal() {
        double total = item1.getPrice() + item2.getPrice();
        assertEquals( total , order.getTotal() , 0.0 );
        LineItem item3 = new LineItem( "Video" , 39.95 );
        order.add( item3 );
        total = total + item3.getPrice();
        assertEquals( total , order.getTotal() , 0.0 );
        assertTrue( order.getTotal() == total );
    }
}

The assertEquals() method used here takes a third parameter. The floating point variants of the assertEquals() method use this third parameter to test your tolerance for floating point accuracy. In this case if the numbers are not an exact match it will throw an AssertionFailedError. Writing up a test case has brought a couple of interface necessities to the forefront. The SalesOrder class will need a no-parameter constructor, and add method that takes a line item as a parameter and a getTotal method that will return a total of some type. The first implementation of SalesOrder will look like this:


public class SalesOrder {
    public SalesOrder() {
        
    }
    public void add( LineItem item ) {
        
    }
    
    
    public double getTotal() {
        return 0.0 ;
    }
}

Both of these will compile at this stage. To run the test case type the following on the command line:


java junit.swingui.TestRunner SalesOrderTest

You should see the following error:


junit.framework.AssertionFailedError: expected:<60.0>but was:<0.0>

In this case the assertTrue() never ran. JUnit stops a test method on the first error it finds. If your test class has other methods, the TestRunner will run those other methods even if a previous method failed. I'll leave it to you to implement the code to make the test method in SalesOrderTest pass.

Running multiple test cases

The demonstration so far has run the test cases separately. For two classes that is not that big a problem, but hundreds of classes would be cumbersome. Fortunately, the developers of JUnit have anticipated this need by adding the TestSuite class. Here is some sample code for the previous tests:


import junit.framework.* ;

public class AllTests {
    public static TestSuite suite() {
        TestSuite suite = new TestSuite();
        suite.addTestSuite( LineItemTest.class );
        suite.addTestSuite( SalesOrderTest.class );
        return suite ;
    }
}

Instead of running either of the previous classes with the test runner you will run the AllTests class. The TestRunner will call the suite method and receive the TestSuite object that contains the other tests. It will then be able to run each test.

That's it

JUnit really is just that simple. There are other ways to implement your tests using JUnit, but I found this method to be the easiest for me. There are many other articles and tutorials on the JUnit website to learn more about using this powerful tool.

Return to Top

Whizlabs XML Certification Exam Simulator Review

By Valentin Crettaz
Software by Whizlabs Software Ltd
USD 74.95



By releasing a new version of Whizlabs XML Certification Exam Simulator, Whizlabs once again confirms its leadership in the IT certification test simulators business.

Whizlabs XML Certification Exam Simulator is targeted at people who would like to be prepared for the "XML and Related Technologies" certification (IBM Test 141). The application provides five mocks exams containing 285 questions with a big emphasis on scenario-based ones. As an added bonus, it also features a brief and concise, yet good, XML tutorial. This test engine will bring you in a real-exam-like situation in which you have 90 minutes to answer 57 questions. It assists you in saving time by allowing you to mark a question and come back to it later. Once you have answered all questions, you may either review your answers (provided time isn't up), or go ahead and finish the exam. In the later case, the tool will generate an evaluation report that gives you feedback on your performance and allows you to browse through the detailed and high-quality explanations. The test reports can be saved into an overall test report containing the reports of all the test you have taken.

Whizlabs XML Certification Exam Simulator also provides a test customizer that allows you to build up your own mock exams. You can choose the kind of questions you want to be asked, the difficulty level of the questions as well as the time you will be given to complete your test. Used correctly, this feature will allow you to be focused, to put your energy and concentrate on specific topics.

The interactive quiz feature contains 115 questions and allows you to build your own quiz. You can preset the kind of questions you want to be asked and decide how much time you want to spend on each question. Once the time is up, your answer is freezed and there is no way to change it. This can be a good way to assess how well you resist to pressure and stress.

I would have expected that the explanations of the questions on the test report be linked with the provided XML tutorial or even with pertinent XML web sites, hopefully this will be included in upcoming releases. Also, the design of the menu bar does not really satisfy to the widely accepted industry standards and would need to be improved. The latter change is underway and should be incorporated in the next version of the tool.

Finally, it is worth mentioning that being committed to bring high-quality products to market and dedicated to its customers, Whizlabs offers an unconditional money back guarantee. It is also worth noting that Whizlabs will soon make an online version of Whizlabs XML Certification Exam Simulator available on the web.

Basically, I very much appreciated this commercial test engine which can turn any XML-unaware into a fair XML-certified developer. The questions are well worded and are often based on practical examples which facilitates comprehension. The explanations given in the answers also satisfied me. Whizlabs is making a safe bet with this tool which is well worth the 75 bucks.

Resources
Trial version
Other product details


Return to Top
Book Review of the Month

JMX In Action
by Simon Brown
Finally, a JMX book you'll love! Unlike other JMX books I've read (even those purporting to be based on "Real-world" experience) this book is firmly grounded with examples and explanations as to why JMX is useful and necessary.

Starting from the first chapter (which is the best architectural overview of JMX I've read) the authors provide clear, easy-to-understand explanations of both the how and the why of JMX. The code examples are readable and clearly explained (the authors specifically call out the relevant parts of each example) making you want to grab an editor and start coding!

They cover all of the major parts of JMX very well, including details on each of the different types of Mbeans. Likewise, their coverage of JMX notification is the best I?ve seen. And, since the book is based on the Sun JMX Reference Implementation with detailed instructions on building and running the examples, it?s easy to try this yourself.

There are a few minor snags that don?t affect the book much. They don't start using UML early enough (the first large-scale example left me scratching my head) and they build a few marginally useful things (a Jini connector, for instance). Also, a bit more detail on other JMX implementations would have been nice. However, it?s still the best of the available JMX books. Buy it if you need to use or build Mbeans! (Kyle Brown - Bartender, October 2002)

More info at Amazon.com More info at Amazon.co.uk

Chosen by Cindy Glass and Madhav Lakkapragada

Return to Top

Managing Editor: Carl Trusiak

Comments or suggestions for JavaRanch's NewsLetter can be sent to the NewsLetter Staff
For advertising opportunities contact NewsLetter Advertising Staff