Testing in Java: Part I – Introduction

As I’ve alluded to, this is the first article in a series to walk through the process of testing an application for production.  We’ll be making a simple REST interface web application that connects to a back-end database.  It will do some basic CRUD operations and I’ll show how I’d test each layer of this application.  Hopefully, you’ll find some of these techniques useful and able to apply them to your own work.  You can download, fork, or view the entire code base from the GitHub repo.

A typical web application has a few tiers: user interface, business logic, and data access.  In the case of this application I’m following the same idea, but have broken out the objects that are being modified into a domain-objects package inside of the project.  This is where we’ll start this series — talking about the objects and how to test them. I’m going to break the pure TDD-style for this series and write an object first, then write a test :).

In an application where you’re dealing with objects that the user is performing a CRUD operation upon you’ll want to think about these first.  The initial design would consist of determining what each of these objects are and create an interface and class embodying those concepts.  In our case we have a simple item that consists of a name and a unique identifier.  I’ve named it: MyItem.  Below, you’ll see the interface for MyItem along with a simple default implementation, MyItemImpl.

package com.laneholloway.unittestingexample.domain;

import java.util.UUID;

public interface MyItem {
    public UUID getGuid();
    public String getName();
}
package com.laneholloway.unittestingexample.domain;

import java.util.UUID;

/**
 * A simple default implementation
 */
public class MyItemImpl implements MyItem {
    private final UUID uuid;
    private final String name;

    public MyItemImpl(String itemName) {
        this(UUID.randomUUID(), itemName);
    }

    public MyItemImpl(UUID guid, String itemName) {
        this.uuid = guid;
        this.name = itemName;
    }

    @Override
    public UUID getGuid() {
        return uuid;
    }

    @Override
    public String getName() {
        return name;
    }

    @Override
    public boolean equals(Object o) {
        if (o == null) return false;
        if (o instanceof MyItemImpl) {
            MyItemImpl that = (MyItemImpl) o;
            if (that.getGuid().equals(this.uuid) && that.getName().equals(this.name)) {
                return true;
            } else {
                return false;
            }
        } else {
            return false;
        }
    }
}

Now that we have the default implementation, we need to have a test for how we want the item to behave within the system. In our case, if the id and the name are the same, the objects are equal. If either is not equal, the objects are not equal. To verify this, we can write a test class using JUnit4. Looking at the code, you’ll notice that I’ve written two of the three tests and I’ve left the last one as an exercise (it really isn’t that hard :)).

package com.laneholloway.unittestingexample.domain;

import com.laneholloway.unittestingexample.domain.MyItem;
import com.laneholloway.unittestingexample.domain.MyItemImpl;
import org.junit.Before;
import org.junit.Test;

import java.util.UUID;

import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertTrue;

/**
 * Simple tests to show off the MyItemImpl
 */
public class MyItemImplTest {
    private MyItem myItemOne;
    private MyItem myItemTwo;
    private MyItem myItemThree;

    @Before
    public void setup() throws Exception {
        UUID testId = UUID.randomUUID();
        myItemOne = new MyItemImpl(testId, "test");
        myItemTwo = new MyItemImpl(testId, "test");
        myItemThree = new MyItemImpl(UUID.randomUUID(), "test");
    }

    @Test
    public void if_uuid_and_name_are_the_same_items_are_the_same() throws Exception {
        assertTrue(myItemOne.equals(myItemTwo));
    }

    @Test
    public void if_uuids_are_different_the_items_are_different() throws Exception {
        assertFalse(myItemOne.equals(myItemThree));
    }
}

Now, pat yourself on the back, with these three classes you’ve created the object that is being modified by the program and tested it to make sure the implementation behaves as expected.

From here, we will examine the more complicated data access layer, then the business logic, and finally, the REST layer.

As always, if you have any comments, concerns, edits that I should make, let me know in the comments below.

2 thoughts on “Testing in Java: Part I – Introduction

  1. Paul Graham once quipped that “Web 2.0” really meant “JavaScript now works”. Nearly ten years later, more and more functionality of our web applications is written in JavaScript. But for those of us who came of age when JavaScript was unreliable, it’s been preferable to test the server-side, while leaving the UI a thin-as-possible shell. Testing the front-end was error prone and brittle.

  2. Even with Selenium, testing the front-end JavaScript is still brittle. Unfortunately, I don’t think the front-end has quite the software engineering processes in place that the back-end has. It’s getting there but it isn’t there yet, the stigma of being a front-end developer needs to be removed before any serious testing and engineering sets in.

Leave a Reply

Your email address will not be published. Required fields are marked *