Unit testing: about easy- and hard-first strategies

Question

I've never written a unit test.

I'm reading The art of Unit Testing by Osherove, and he explains a way to choose where to start when you're writing tests for legacy code. Basically you end up with two kinds of tests to write: easy (on components with few dependencies) and hard (on components with many dependencies).

Then he says that starting from the hard ones you have to be more experienced, but that it lets you refactor and make testable a wide part of the system, making later work much easier.

But isn't it true the way around too? I mean, if you start from easy tests, shouldn't you end up making hard tests easier?

Answer 1

Go for the easy tests first, if only because when you start writing the hard tests, you'll be able to do some regression to ensure that your refactorings didn't break anything.

As per your question: That shouldn't be the case unless the system is incredibly highly coupled. The easy tests shouldn't force refactorings to make the harder tests easier. This may end up being the case, but your code should be as orthogonal as possible, thus making your tests just as orthogonal.

You could make a stronger case for your integration tests helping to do that.

Answer 2

I would start with the easy unit tests first just to get the experience of writing them under your belt. Ensure that your tests are thorough and that you are testing all of the cases you can think of for all combinations of input to the classes/methods you are testing. Starting with writing harder tests may discourage you from unit testing at all.

Answer 3

if you start from easy tests, shouldn't you end up making hard tests easier?

After implementing easier tests the hard tests will become a tiny bit easier in the sense that you get experience as @Bernard stated.

however the difficulty with the hard tests is that non tdd developed modules are usually tightly coupled and it is nearly impossible to test functionality in isolation.

my advice:

• do some easy tests to get experience.
• create integration tests for the hard cases.
• don't create unit tests for the hard cases as long as you are a tdd-novice.
• do test-driven development for new features to get experience how implementation with loosely coupled functionality

Answer 4

The legacy components with many dependencies are going to be hard no matter how many of the easier components you do. The reason is simple, in order to test you have to break the hard-coded dependencies without breaking the dependent component. Typically, the component with a lot of dependencies is doing a lot of stuff and mixing those dependencies in ungodly ways. So the job of breaking out and testing those dependencies while maintaining the same behavior is that much tougher and won't be improved by your efforts on simpler components.