|
Under What Conditions Should You Not Test Get() and Set() Methods?
JUnit Questions and Answers
(Continued from previous question...)
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());
}
(Continued on next question...)
Other Interview Questions
| 