Under what conditions should I test get() and set() methods?

Question

I could not confirm whether to do these tests. It seems the set and get method is so simple,such as:

setA(String A) {
    this.A = A;
} 

getA(){
    return A;
}

Any ideas would be appreciated!

Thanks, Joseph

Answer 1

They are all same, I say like blank interfaces or business classes. Preprocessing should enable all needed or they are other kinds (doers that both shall return like respond and take 2 variables) language agnostically (even POSIX exit that now is void should use arguments since knowing way is very important)

Answer 2

Make a cost/benefit analisis

What would it gain

• knowing that the private variable indeed get read/written

What would it cost

• the time taken to write the testcase

• the time spend, each time executing your testsuite

---

If you know there are no observable side-effects calling the getter or setter, I wouldn't bother.

Answer 3

Writing test cases for methods which can't fail seems disproportionate to me. Only if the value of A is initialized by configuration or something which could fail it is worth testing.

EDIT: Another example when testing makes sense could be a flag 'overdrawn' if an accounts balance becomes negative and you want to check whether the flag was set correctly after calling a method withdraw().

Answer 4

General rule: Not much point in writing tests for getters and setters. Only if they have some additional logic, ie. are not pure accessors, you should write the tests.

Answer 5

Yes, in your case they are trivial - but on the other hand - two simple tests that fully count for quality metrics ;-)

I would create tests. Your application actually relies on the behaviour that the methods really store/access the field values and do not change anything.

Maybe, one day someone decides to change a field type or to add some unit conversion code to a setter/getter - a test will show, if the code still works or it will show, that more work is needed.

Answer 6

I've only seen a very few problems with getters and setters in the wild, and only one of those could have been detected via a unit test, and only then if all of the getters and setters were tested together, rather than in individual test methods.

Consider the copy/paste mistake of reusing the same field from two different pairs of getters/setters. I.e.,

public void setA(Object a) {
  this.a = a;
}
public Object getA() {
  return a;
}

public void setB(Object a) {
  this.a = a;
}
public Object getB() {
  return a;
}

Unit tests that focus on one setter/getter pair at a time won't expose the problem.

Modern IDEs will generate getters and setters on request, so this mistake is unlikely, but not everyone uses modern IDEs. (A vi user created the bug above.) And if these methods reside in a simple data-holder object, the problem may only show up a bit far from the cause.

For this reason, if I test getters and setters at all (and I often don't), it's from a single test method that calls all of the setters first with distinct values, then asserts on all of the the getters.

One problem you've got to live with, though, is that there's no guarantee that a method that starts life as a "simple" getter or setter will stay that way when someone else gets their hands on the code and decides, say, that a geetter is a good place do something that involves a side-effect.

Answer 7

The only time I would write tests specifically for set() and get() methods, is if there is some sort of logic inside them. Eg. limit an integer to between 1 and 8

public void SetA(int a)
{
  if(a > 8 || a < 1)
  {
    throw new IndexOutOfBoundsException();
  }

  this.a = a;
}

Even though the code above is a very simple example, when you do this type of logic, it can be a good idea to run a test on them. Mainly for when your business rules change and you have to limit it to between 9 and 1 :)

Answer 8

Unit tests are supposed to be the documentation for how the system is supposed to work. Although people often skip unit tests for Properties because the functionality is trivial, if the tests are the documentation and especially if someone else is going to do the implementation then tests for Properties should be written. That said, when I am both writing the tests and doing the implementation, I usually skip writing tests for Properties unless they do something more than a simple get/set or if I have spare time, which is a rare thing.

Answer 9

A smart man once said "Test until fear turns to boredom". If you no longer fear that your super-simple code will break, don't write tests unless you're not bored writing those tests. And don't write tests just to "improve your metrics," that's just gaming the system. Write tests to make sure your code works, to improve robustness, and to create confidence that you can refactor freely.