Performance Zone is brought to you in partnership with:

Mike lives in Edmonds, Washington where he enjoys experimenting with new development frameworks and expanding these to the cloud. Mike continually pushes his knowledge utilizing test driven development and different development methodologies. This site is just a duplication/re-syndication of the original blog hosted at http://www.ensor.cc Mike is a DZone MVB and is not an employee of DZone and has posted 13 posts at DZone. You can read more from them at their website. View Full User Profile

A Brief Overview of Java Assertions

09.21.2012
| 4888 views |
  • submit to reddit

First, what are asserts? An assertion is a predicate (a true–false statement) placed in a program to indicate that the developer thinks that the predicate is always true at that place. [wikipedia]

Traditional asserts

Traditional testing frameworks started with the built in keyword assert.

An example of the keyword assert:

assert <condition> value

Assert has a few drawbacks including stopping the test execution and lengthy and hard to describe assert statements.

Second generation assertions

Along comes JUnit's assert framework. Built on top of the assert keyword, JUnit provided developers the ability to be more descriptive about the testing statements.

An example of JUnit's asserts:

    // asserts that the condition must be true  
    assertTrue("This should be true", "abc".equalsIgnoreCase("ABC"));  
    // asserts that the object must not be null  
    assertNotNull(new MyObject());  
    //...  
    assertFalse(false == true);  
    //  
    assertNull(null);  
    // etc...  

While there are some improvements on readability and usability to the basic assert keyword provided by JUnit, they share some of the same drawbacks in that many developers just use the "assertTrue()", "assertEquals()" and "assertFalse()" methods still providing a very cryptic assertion statement.

Third generation assertions

In an effort to guide developers into writing test assertions that are more readable and usable the Hamcrest library was created which switched the philosophy from many assert functions to just one basic function. The fundamental thought is that the assert is the same but the conditions will change. Hamcrest was built using the concepts of BDD (behavior driven design) where the test assertion is closer to that of a sentence.

An example of hamcrest assertions:

    @Test  
    public void showoffSomeHamcrestAssertsAndMatchers() {  
        // asserts that string "abc" is "ABC" ignoring case  
        assertThat("abc", is(equalToIgnoringCase("ABC")));  
        assertThat(myObject.getFirst(), is("Mike!"));  
        assertThat(myObject.getAddress(), is(notNullValue));  
    }  

Hamcrest is a great improvement on top of the JUnit framework providing a flexible and readable testing platform. Hamcrest + JUnit is a comprehensive testing framework and when combined with Mockito (or other mocking framework) can provide a very descriptive and thorough unit testing solution. One of the drawbacks to using Hamcrest is that while descriptive, multiple assertions must be made to ensure that a test case has been covered. Many TDD purest agree that a test case should contain one and only one assertion, but how is this possible with a complex object? (purest will say refactoring, but oftentimes this is not feasible)

Fourth generation frameworks

And finally we come to the present with the latest assertion frameworks. Fest Assertion framework takes off where Hamcrest stopped providing a fluent style assertion framework giving the developer the ability to test objects with a single assertion.

An example of Fest assertions:

    @Test  
    public void getAddressOnStreet() {  
        List<Address> addresses = addressDAO.liveOnStreet("main");  
        assertThat(addresses).hasSize(10).contains(address1, address2);  
        assertThat(stringObj).hasSize(7).isEqualToIgnoringCase("abcdefg");  
    }  

As you can see, FEST exceptions provide a cleaner approach to assertions. FEST is very extensible and easy to use.

Conclusion

Assertions are a key tool in a professional developer's toolbox in which to stress test their code. This post is a part in a series with the culmination being a fluent style ExpectedException mechanism, backed by Fest, in which to add better clarity to your test cases when exceptions are being introduced. Feel free to read the lead up to this post; Allowing known failing JUnit Tests to pass test cases.

NOTE: This blog is providing an overview on assertion frameworks it should be noted that there are various other second and third generation testing frameworks that strive to provide better clarity and usability for testing including notables such as TestNG and JTest.

 

Published at DZone with permission of Mike Ensor, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)