Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Junit Test of Setters and Getters of Instance Variables

When creating test cases for setters and getters of instance variables within the object. What is the best approach? Here I use the get and set methods within my tests. Would this be poor testing strategy?

/**
 * Test of setFlightNumber method, of class Flight.
 */
@Test
public void testSetFlightNumber() {
    System.out.println("setFlightNumber");
    int flightNumber = 1000;
    Flight instance = new Flight();
    instance.setFlightNumber(flightNumber);
    // TODO review the generated test code and remove the default call to fail.
    assertEquals(instance.getFlightNumber(), flightNumber);
}

/**
 * Test of getFlightNumber method, of class Flight.
 */
@Test
public void testGetFlightNumber() {
    System.out.println("getFlightNumber");
    Flight instance = new Flight();
    int expResult = 1000;
    instance.setFlightNumber(1000);
    int result = instance.getFlightNumber();
    assertEquals(expResult, result);
}
like image 580
user3126529 Avatar asked Jan 25 '14 18:01

user3126529


People also ask

Should getters and setters be unit tested?

If you tests use the getters/setters to achieve their goal of testing the "real" functionality, then that's good enough. If, on the other hand, your getters and setters do more than just get and set (i.e. they're properly complex methods), then yes, they should be tested.

How do you write JUnit test cases for POJO classes?

Here we will see one complete example of JUnit testing using POJO class, Business logic class, and a test class, which will be run by the test runner. Create EmployeeDetails. java in C:\>JUNIT_WORKSPACE, which is a POJO class. get/set the value of employee's name.

Are getters and setters instance methods?

Getter and setter method The method that is used to set/modify the value of a private instance variable of a class is known as a setter method and, the method that is used to retrieve the value of a private instance variable is known as a getter method.

What is @after in JUnit?

org.junit Annotating a public void method with @After causes that method to be run after the Test method. All @After methods are guaranteed to run even if a Before or Test method throws an exception.


1 Answers

The main principle of unit testing is that you test a simple unit of code; that is, each method should be tested on its own merits.

This means we can't use the get method in our set test, and vice versa - you're not testing the individual unit of code that is the single method.

Given that...

Let's say we have a PlainOldJavaObject with a field value that we want (for some reason) to test the validity of setters and getters for. The only appropriate way to do this is through the use of reflection.

Here's my class declaration, which is pretty skinny:

public class PlainOldJavaObject {

    private String value;

    public String getValue() {
        return value;
    }

    public void setValue(String value) {
        this.value = value;
    }
}

I now set up my test class to make use of reflection; specifically using the Field class:

public class PlainOldJavaObjectTest {

    @Test
    public void testSetter_setsProperly() throws NoSuchFieldException, IllegalAccessException {
        //given
        final PlainOldJavaObject pojo = new PlainOldJavaObject();

        //when
        pojo.setValue("foo");

        //then
        final Field field = pojo.getClass().getDeclaredField("value");
        field.setAccessible(true);
        assertEquals("Fields didn't match", field.get(pojo), "foo");
    }

    @Test
    public void testGetter_getsValue() throws NoSuchFieldException, IllegalAccessException {
        //given
        final PlainOldJavaObject pojo = new PlainOldJavaObject();
        final Field field = pojo.getClass().getDeclaredField("value");
        field.setAccessible(true);
        field.set(pojo, "magic_values");

        //when
        final String result = pojo.getValue();

        //then
        assertEquals("field wasn't retrieved properly", result, "magic_values");
    }

}

In the first test, I am making certain that the field is read by reflectively accessing the value contained in the field for the instance of PlainOldJavaObject. Without violating the integrity of the declared class*, I am confident that the field is being set appropriately.

In the second test, I assume that the value has already been set to something prior, so the set-up involves populating the field with a known default value. When I read the value back, I am asserting that the value read back is the value that we know it was originally set to.

Ultimately, if you have a lot of setters and getters, you'll have to do code like this (since, if you rely on the assumption that your setters and getters "just work", like you are in your tests above, your test cases may be invalid).

*: Mind you, reflection is a quick and fast way to get into extreme trouble with undefined behavior, and you have few guarantees of object immutability. You're taking the shrink wrap off of the language and are doing strange and unusual things. Proceed at your own peril.

like image 103
Makoto Avatar answered Oct 21 '22 22:10

Makoto