Testing scenario separation

Question

@Test
public void addElemenInEmptyList() {
    List<Integer> list = new LinkedList<Integer>();
    int data = 122;
    boolean added = list.add(data);
    assertNotNull("Object not added", added);

    Integer addObj = list.get(0);
    assertNotNull("Object not found", addObj);
    Assert.assertEquals("Fetched value is different", data, addObj.intValue());
}

I have written small JUnit test for testing Java's LinkList(for learning JUnits), in above JUnit I am testing three things

1. List gets modidified ( assertNotNull("Object not added", added))
2. Able to get first data (not null)
3. Data added, tring to get it and validating it with passed data.

This Junit may fail for three different reason. Is this a proper approach for writting it? Could please you suggest any better approach for it

Answer 1

I would recommend to split up the method. I would test each aspect of a method api in one test method. I would do this, because you will get a clear feedback from your tests about what works and what fails. E.g.

First take a look at the javadoc of the method you want to test. This is the contract and a test should always make sure that this contract is fulfilled.

For example the List.add(E element) javadoc says:

Appends the specified element to the end of this list (optional operation).

Lists that support this operation may place limitations on what elements may be added to this list. In particular, some lists will refuse to add null elements, and others will impose restrictions on the type of elements that may be added. List classes should clearly specify in their documentation any restrictions on what elements may be added.

Returns true if this collection changed as a result of the call

The List.add(E element) javadoc also says that some aspects of this method are defined by implementations. E.g the LinkedList javadoc says

Doubly-linked list implementation of the List and Deque interfaces. Implements all optional list operations, and permits all elements (including null).

Therefore the add method's tests should cover these aspects:

• null values are allowed to add
• add appends element to the end of the list
• trueis returned if the list changed.

So my first test implementation would look like this

public class LinkedListTest {

    /**
     * adding <code>null</code> must be possible.
     */
    @Test
    public void addNullElement() {
        LinkedList<Integer> list = new LinkedList<Integer>();

        boolean added = list.add(null);
        assertTrue("expected that null was added", added);
    }

    /**
     * adding a not <code>null</code> element must return <code>true</code>.
     */
    @Test
    public void addNotNullElement() {
        LinkedList<Integer> list = new LinkedList<Integer>();

        boolean added = list.add(Integer.valueOf(1));
        assertTrue("expected that element was added", added);
    }

    /**
     * add must append element to the end of the list
     */
    @Test
    public void addElementToTheEndOfTheList() {
        LinkedList<Integer> list = new LinkedList<Integer>();
        list.add(1);
        list.add(2);

        Integer firstElement = list.get(0);
        assertEquals("expected first element to be 1", Integer.valueOf(1),
                firstElement);

        Integer secondElement = list.get(1);
        assertEquals("expected first element to be 2", Integer.valueOf(2),
                secondElement);
    }

}

But there is even more. The List.add(E element) extends Collection.add(E element), because List extends Collection. So you must also take the Collection.add(E element) javadoc into account. It might add additional aspects. Nevertheless you can also build a hierarchy of your tests to cover this. E.g. LinkedListTest that extends AbstractListTest that extends AbstractCollectionTest. Than you can put the test aspects of each interface in the appropriate abstract test class.