views:

171

answers:

9

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

A: 

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)

LarsOn
+1  A: 

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.

Lieven
A: 

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().

stacker
+3  A: 

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.

fish
If they're not pure accessors, it's arguably misleading to have them as getters and setters (imho).
cletus
@Cletus: I agree with that.
fish
Having getters and setters never be allowed to do anything but set private variables is not really any meaningful form of encapsulation - you may as well have public fields!
Steven Schlansker
@Steven it's a blurry line. At some point the level of side effects riches a point where "accessoor" is not an accurate term.
cletus
Well one example where the setter needs to do something else is when the setting of a property must fire an event. And this case should of course be covered with tests.
fish
+1  A: 

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.

Andreas_D
I would argue that the property would get used in other testcases anyway. If it weren't, it shouldn't be there.
Lieven
A practical compromise for a bean: one test that covers all 'trivial' getters and setters. But public methods are an interface to classes and thus should be tested and reliable.
Andreas_D
+2  A: 

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.

Dave W. Smith
+2  A: 

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 :)

Thomas Winsnes
Yes, it is necessary.
Joseph
A: 

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.

Bill W
+1  A: 

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.

dplass