November 19, 2012

How to test a Custom Exception using custom FEST assertions


This is part three of my posts on assertions testing using Fest, JUnit and custom Exceptions. The first post was covering the basics of assertions, then followed up with testing custom Exceptions using JUnit and JUnit's ExpectedException class. At this point you should know that you have a custom Runtime Exception class and you would like to test it using the Fluent API provided by FEST.

Custom Assertions with Fest

This blog post will not go into the details on creating a custom assertion, but the solution posted in the Github project does contain a custom assertion. In addition, please refer to the official site docs.

Building off of the last post, you will see that ExpectedException is a great improvement over the @Test(expected) and Try/Catch techniques, however the ExpectedException object can still be improved by adding in a fluent-style API backed by Fest Assertion project. So, how do you do it? Let's get right to the solution!

Expected Exceptions with FEST and JUnit @Rule

Now that we have an understanding of FEST assertions, JUnit's @Rule functionality and ClickConcept's @ExpectedFailure we can combine the first two to provide fluent-style expected exception behavior while testing the assertion class using @ExpectedFailure annotations.

Testing your custom exception with FEST

Let's begin by creating a new @Rule object "ExpectedException" which extends TestRule. When creating the class, we will expose the construction through a simple factory method to return a new ExpectedException. The default factory will return a base implementation where the functionality is muted in all other cases where exceptions are not desired.

We can start out with the code first, but I will explain that in order to build your own custom Fluent API for FEST, you must re-create the API for the base exception assertion. The fluent API you create will be in addition to the FEST exception assertion class. Fluent API help was derived off of several blogs, but the most informative has been

NOTE: AbstractExpectedException encapsulates the base API for FEST's ExceptionAssertion. The code for this is found at the Github site:

public class ExpectedCustomException extends AbstractExpectedException<ExpectedCustomException> {

    private Integer code;

    public static ExpectedCustomException none() {
        return new ExpectedCustomException();

     * Checks to see if the CustomException has the specified code
     * @param code int
     * @return AbstractExpectedException
    public AbstractExpectedException hasCode(int code) {
        // method telling class that a custom exception is being asked for
        this.code = code;
        return this;

    protected void checkAssertions(Exception e) {
        // check parent's exceptions

        if (getCode() != null) {
            // FEST Custom Assert object

    private Integer getCode() {
        return code;



In this example, my CustomException has exposed a "code" to store when the exception was created. In order to test this my custom ExpectedException object must look for the proper code on the CustomException object, in a fluent manor.

Here is an example test case to explain how to use your new fluent API Custom Exception test. Take note of the third test case to see the Fluent API in use! (NOTE: Full test cases are available on my github account.

public class CustomExceptionTest {

    public ExpectedCustomException exception =

    public ExpectedTestFailureWatcher expectedTestFailureWatcher =

    public void hasCode_worksAsExpected() {
        throw new CustomException("Message", 123);

    public void getCode_fails() {
        throw new CustomException("Message", 123);

    public void getMessageAndCode_codeFailsFirst() {
        throw new CustomException("Message", 123);



Thank you to those of you who have read through this little series covering assertions, how to test exceptions (both the exception flow and custom exceptions) and then on to testing your custom exceptions using FEST assertions. Please come back to my blog in the near future where I will have a REST API checklist to look over when architecting your next REST API.

Those who are reading this blog are most likely a small subset of the software development community, but if you are not, and you find the idea of a fluent-API really cool (as I do), please check out the FEST assertion library. If you are new to test driven development, please take up the practice and try applying to your code immediately. If all developers used TDD as a general practice, the level in quality would grow world wide!


Mohamed Abdellatif said...

شركة رش مبيدات بحائل
شركة رش مبيدات بالاحساء
شركة رش مبيدات ببريدة
شركة رش مبيدات بابها

Deepa said...
This comment has been removed by the author.
Ali jan said...

Training over time - research shows that two weeks after training, people typically retain 2-4% of what they learned... unless they've been actually using what they learned; Salesforce training in Chennai

Haris said...

I feel satisfied with your share.
It's very helpful for me and I am so happy to see your blog.
Thank you for sharing it with us. law dissertation help

Sris Law said...

Awesome blog! This is a helpful article. This blog is clear and with lots of useful information. Thanks for sharing more blogs.
Virginia Family Laws
Virginia Sex Crimes Lawyer
Divorce Lawyers Near Me Virginia