2

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?

Community
  • 1
  • 1
CodeGrue
  • 5,865
  • 6
  • 44
  • 62

2 Answers2

2

Integration tests just test to see if the interface is returning what was expected. Unit tests are very specific and very small tests to confirm the internals are working. They help expose dark areas of the code that would be very difficult for integration tests to find. Integration tests are great if you're never allowed to ever change or reuse the components that are being tested.

Unit testing gives you confidence over functions of code that may not be in use right now, or may be subject to odd situations that cause them to misbehave or fail. Its kinda like stress testing the individual gears of a car, rather than abusing the entire car to get them to fail.

In regards to data manipulation, if you're having difficultly making unit tests on the process, then it should be pointing to you that you haven't modularized it well enough.

monksy
  • 14,156
  • 17
  • 75
  • 124
  • I guess what I am saying then is that I am testing a single layer, data access methods, but that I have it pull from a "sample" database with known data as the source for the test. This saves time from having to fabricate data for each unit test. So I gues that would be a hybrid test? – CodeGrue Jul 27 '12 at 12:26
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.

hvgotcodes
  • 118,147
  • 33
  • 203
  • 236