Question

I had a discussion about the value of Unit testing here:

Why should I bother with unit testing if I can just use integration tests?

but what I think I could infer from that is that Unit testing is good for discreet logic methods, but when data is being manipulated, you need to fall back onto integration tests.

The issue I have is in real world LOB applications, 99% of what they do is manipulate data, so does that mean only 1% of the typical application lends itself to Unit testing?

Answer 1

I would still use a unit test when data is involved. For example, when I test my response handlers in a webapp, I don’t want to have to fire an actual ajax request to test my handler. Instead, I put some example json in a string, then pass it to my handler.

If I’m writing an application that reads data from a file, my data processing methods will be completely separate from the code that actually deserializes the file. So in this case, again, I would can some real-world data, and pass it to the data processing methods under test.

You will see that using unit tests also informs the design of your code. In these examples, the methods/classes that do things with the data are completely separate (i.e. decoupled) from the way I am getting the data.

As an note, I would probably throw some integration/functional tests in there as well for good measure, but I completely disagree with the notion that unit tests are only applicable 1% of the time.