Writing additional code to perform unit-tests involving ivars OK or should be avoided at all costs? [closed]

Question

Still a novice when it comes to writing unit-tests I often come across cases where I'm left scratching my head as to what is the right way to do things. Writing tests for a planned design I came across one of these dandruff-inducing instances. My design:

One ViewController sending the message to a dataFetcherClass based on the user's input. (The below code has been changed to protect the innocent).

-(void) userPushedLocalBusinessButtons{
    [_businessDataFetcher fetchLocalData];
}

-(void) userPushedWorldwideBusinessButtons{
    [_businessDataFetcher fetchWorldwideData];
}

The data format is identical for these actions, it's the location the dataFetcher should collect the data from that changes. So, in the BusinessDataFetcherClass I have these methods:

-(void) fetchLocalData{
    _dataAddress = @"localData.json";
    [self fetchData]; 
}

-(void) fetchWorldwideData{
    _dataAddress = @"worldwideData.json";
    [self fetchData]; 
}

The fetchData method fetch the data asynchronously and send a notification with the collected data when done. Now, I would like to write unit tests checking that the ivar _dataAddress has changed when fetchLocalData or fetchWorldwideData has been executed.

This is clearly not possible without altering the code. Some would say that this could easily be remedied by making _dataAddress into a public property, and that's one solution. Another would be to create a method returning the value of the _dataAddress ivar. I am not entirely happy with either alternative as they in both cases force me to change the code just for the tests, rather than improve the overall quality of the actual code-base itself.

I landed on the second alternative and included a method -(NSString *) dataAddress; My question (as stated in the headline) is whether this is OK? Is my design the problem? Obviously the number one goal of TDD is to avoid regression, but I believe improving the overall code-quality is also an important goal. Is adding the occasional fluff to be expected?

Answer 1

I would like to write unit tests checking that the ivar _dataAddress has changed when fetchLocalData or fetchWorldwideData has been executed.

When you write a unit test, it should test the external behavior of a class. This is an implementation detail of the class. If you want to change the way fetching data works, the class might still work while the unit tests fail. This makes your unit test annoying, not helpful.

fetch the data asynchronously and send a notification with the collected data when done.

It sounds like this is the external behavior of those methods in that class. This is what you should write your test to check. I don't know objective-c, so here's a psuedo-code example:

setup expected local data (preferably with a mock)
call fetchLocalData on BusinessDataFetcherClass 
wait a little bit
check that local data is populated on ViewController

Is my design the problem?

Your design here does make writing tests a little harder, though it isn't a big problem. In particular, that "wait" which needs to happen in the test. The design problem that your tests are pointing out is that your class has at least two responsibilities: fetching data and managing asynchrony. If you split those responsibilities apart, they would each be easier to test.

Obviously the number one goal of TDD is to avoid regression, but I believe improving the overall code-quality is also an important goal. Is adding the occasional fluff to be expected?

I don't think you probably need more fluff in this case, but it does happen with unit tests sometimes. When you write code with tests, you end up with two clients of your code: the test code and the production code. It's the need to satisfy two client in different contexts that forces some of this "fluff" in, or forces some design changes. The good news is that when you have a design that can easily satisfy two client, you will probably be able to satisfy a third and a fourth fairly easily, if the need should arise. To me, this effect is one of the most important benefits to TDD.

Answer 2

You don't want to test the internal state of your class -- this makes no sense. The only thing you care about is what your class is doing in its interactions with the outside world (whether info is going inwards or outwards or both ways).

To put it another way: once you've written a test for your class, rewriting the implementation (internals) of your class while maintaining its visible behaviour should not break your tests. If it does, your tests are broken IMO.

A good way of testing the behaviour of your class is to use Mock objects -- for example, see OCMock for iOS.

Mock objects allow you to test the behaviour of your target class. In order to do this, you need to write your target class in a certain way: in your example, you need to be able to pass in a network provider class, rather than have your class go off and use a certain provider which is hardcoded (re-usable components should never configure themselves, but be configured). Once you've set things up this way, your unit test class can pass in a mock network service provider which checks that the correct URL is being hit.

Mock objects might seem convoluted at first glance, but you're testing the correct thing -- the behaviour of your target class -- without polluting it with any special testing method etc.

Note also that making your code amenable to testing is also making it more amenable to re-use: your test cases become a second 'user' of your code.

Answer 3

I also am not an ObjectiveC developer, but I think that the reason you're posting this is because you're listening to your code, and your code's telling you that something isn't quite right.

I would ask what you're doing with the results of the fetchData call? I suspect you're rendering the data somewhere. If iOS is rendering it, then there's probably a callback somewhere that you can assert rather than asserting the instance variable. If you're updating the UI from within the class, it will make it easier to test if you introduce an Observer to decouple your UI and your code that's fetching the data. You can then have your test register as the receiver and assert your state change there.

Hope that helps!

Brandon