views:

31

answers:

1

I decided to add unit tests to existing project (quite big one). I am using "google toolbox for mac" for various type of STAssert... and OCMock framework.

But I think I'm testing wrong. For example, I have public function saveData, which doesn't return anything and only change internal state of the object. Should I test it? Due to encapsulation principle - I don't have to worry much about object implementation and I mustn't depend on private variables (because they can change/be deleted in the future)

@implementation Foo
-(void) saveData {
 internalData_ = 88;
}

In real project this function saveData is 100 lines long and it's change a lot of private variables of the class.

So, should I test it or not? I have a little previous experience in unit testing and cannot make decision by my own.

+2  A: 

Does the internal state that gets changed affect any later calls on that object? If so, you should include it in a unit test like

  • Test a()
  • Do saveData()
  • Test a() again

Even if not, it might be a good idea to unit test it. Not for determining whether other code will break by using this method, but for automatically testing the correct implementation of the method. Even though the method doesn't return anything, it probably still has some kind of contract ("If I call it, this must happen") and you should check if what should've happened, happened (e.g. a line added in a log file, or something).

Now, how to check that if the method doesn't return anything, is another question entirely. Ironically enough, that's an implementation detail of the unit test.

Bart van Heukelom