Under What Conditions Should You Not Test Get() and Set() Methods?

The JUnit FAQ provides a good answer to this question:

Most of the time, get/set methods just can't break, and if they can't break, then why test them? While it is usually better to test more, there is a definite curve of diminishing returns on test effort versus "code coverage". Remember the maxim: "Test until fear turns to boredom."

Assume that the getX() method only does "return x;" and that the setX() method only does "this.x = x;". If you write this test:

    @Test
    public void testGetSetX() {
        setX(23);
        assertEquals(23, getX());
    }

then you are testing the equivalent of the following:

    @Test
    public void testGetSetX() {
        x = 23;
        assertEquals(23, x);
    }

or, if you prefer,

    @Test
    public void testGetSetX() {
        assertEquals(23, 23);
    }

At this point, you are testing the Java compiler, or possibly the interpreter, and not your component or application. There is generally no need for you to do Java's testing for them.

If you are concerned about whether a property has already been set at the point you wish to call getX(), then you want to test the constructor, and not the getX() method. This kind of test is especially useful if you have multiple constructors:

    @Test

    public void testCreate() {
        assertEquals(23, new MyClass(23).getX());
    }