Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
1  
You need to sit down and write couple of tests and find out for yourself. –  CodeART May 3 '12 at 14:54
    
Before you even try the "hard" cases, give chapters 3-5 a good read. That is, learn how Mocks can make your life better. –  Matthew Flynn May 3 '12 at 15:58
    
@MatthewFlynn I did, actually until I haven't read them I felt like unit testing would be quite masochistic. Thank you all for the answers. –  bigstones May 3 '12 at 16:18
    
If you develop in a TDD way then more of your tests should end up easy as you end up writing code which is less tightly coupled, with fewer dependencies. *8') –  Mark Booth May 4 '12 at 9:54
add comment

4 Answers

up vote 2 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.