What are the disadvantages of writing code before writing unit tests?

Question

I have always seen the recommendation that we should first write unit tests and then start writing code. But I feel that going the other way is much more comfortable (for me) - write code and then the unit tests, because I feel we have much more clarity after we have written the actual code. If I write the code and then the tests, I may have to change my code a little bit to make it testable, even if I concentrate much on creating a testable design. On the other hand, if I write the tests and then the code, the tests will change pretty frequently as and when the code shapes up.

As I see a lot of recommendations to start writing tests and then move on to coding, what are the disadvantages if I do it the other way - write code and then the unit tests?

Answer 1

Red is the answer. Red is what you get from TDD's red-green-refactor cycle that you can't get, test-last. First, write a failing test. Watch it fail. That's your red, and it's important. It says: I have this requirement and I know my code isn't satisfying it. So when you go to step 2 (green), you know, with just as much certainty, that your code now is satisfying that requirement. You know that you've changed your code base in such a way as to satisfy the requirement.

Requirements (tests) developed after the code, based on the code, deprive you of that kind of certainty, that confidence.

Answer 2

If you write the code, and then the tests, it's all too easy to fall into the trap of writing the tests so that the code passes, rather than writing the tests to ensure the code meets the specification.

That said, it's definitely not the only way to do things, and there is no "best" way of developing software. If you put a lot of upfront work into developing test cases, you don't know whether your proposed architecture has any flaws until much later - while if you developed the code first, you'll run into them sooner and can redesign with less sunk effort.

Answer 3

Actually, people get hung up on TDD is about testing, though they forget about the other two letters in the acronym. Something which can be read over here: TDD without the T or TDD is not about Testing.

The thing is I've learnt a plethora of other stuff that is tightly knit with TDD. It doesn't matter if you do test first: What matters is thinking about software design.

In order to even be able to write unit tests "the right way", i.e. so they are isolated, quick and automated, you'll hopefully notice that it takes some rethinking about how to arrange your code in a way that your code becomes easier to test.

Personally I learnt myself the SOLID principles without knowing there was such a thing written. This is because writing unit tests forced me to rewrite classes so they won't become overly complex to test. It led to things like:

• I had to move functionality, that either didn't made sense or resided in private methods, over to separate classes so I could test them separately. (Single Responsibility Principle).
• I had to avoid large inheritance structures and extend implementations with composition instead (prominent in Open-Closed principle).
• I had to be smart about inheritance, I used abstract classes whenever I saw common code that could be shared and used stub methods (Liskov Substitution Principle).
• I had to write interfaces and abstract classes so I could test classes in seperation. Which inadvertedly leads you to write mock objects. (Interface Segregation principle)
• Because I wrote a lot of interfaces and abstract classes I started to declare variables and parameters to use the common type (Dependency inversion principle).

Even though I don't do test-first all the time, I do happen to follow good OO-principles and practices that you start to follow, just to make testing a bit easier. Now I am not writing code for its own sake. I wrote code so it can be easily tested or more importantly; easily maintained.

Answer 4

All of the other answers are good, but there is one point that wasn't touched on. If you write the test first, it ensures that tests get written. It is tempting, once you've written working code, to skip the tests and just verify it through the UI. If you have the discipline to always have a failing test before you write code, you can avoid this trap.

Answer 5

If you write your tests first, it gives you another chance to think about your design, before that design is "cast in stone."

For example, you may think that you need a method that takes a certain set of parameters. And if you wrote the code first, you'd write it that way and make the test fit the specified parameters. But if you write the test first, you might think "wait a minute, I wouldn't want to use this parameter in mainline code, so maybe I should change the API."

Answer 6

As I see a lot of recommendations to start writing tests and then move on to coding,

There's a real good reason for this.

If you say "do what feels right", people do the dumbest, craziest things.

If you say "write tests first", people at least might try to do the right thing.

what are the disadvantages if I do it the other way - write code and then the unit tests?

Usually, a lousy test and a design that has to be reworked to be testable.

However, that's only a "usually". Some people evolve the designs and tests in parallel. Some people put testable code in place and write tests with no rework.

The "Test First" rule is specifically there to teach and instruct people who have no clue at all.

In a similar way, we're told always to look "both ways" before crossing the street. However, we actually don't. And it doesn't matter. I live in a right-hand drive country and I only need to look left when starting to cross.

When I visit a left-hand drive country, looking left only could get me killed.

The rules are stated very strongly for a reason.

What you do is your own problem.

Answer 7

the point of writing the test first is it makes you think about

• how to test the code
• the interface the code must present to be testable

if you're doing something simple, it probably doesn't matter which one you write first (though it is good to cultivate the test-first habit) as the test will be simple and the interface will be obvious

but TDD scales up into acceptance tests, not just unit tests, and then the interface becomes non-trivial.

Answer 8

First off if you do not write your tests first then you are not doing Test Driven Development (TDD). The benefits are numerous and often hard to believe until you practice it multiple times. Here are the benefits that I have received doing TDD over traditional development:

1. A safety net of tests - allows you to make big changes without the fear of breaking something unknowingly
2. Organic design - the design I end up with is usually different that the design I would have done from scratch and it has always been better
3. Productivity - working towards small goals (pass this one test) and making it (all tests pass) works really well for me and keeps me motivated. Add in a pair and my productivity reaches new highs.

Books: Beck, K. Test-Driven Development by Example

Good example: http://jamesshore.com/Blog/Lets-Play/

Answer 9

When you write a test, how do you know it will detect a fail condition? The answer is "test the test". How you do that is to write the test first, see it fail, and only see it pass when the unit under test has been coded successfully (the red/green/refactor cycle mentioned in one of the other answers).

Writing the code first and then the test leaves open the question of whether the test would show an honest fail.

Remember that your tests express specification. If you have to revise your tests as your code "shapes up", it suggests that your specifications are changing. That may or may not be a good thing. It could mean that your understanding of the problem was not initially correct. On the other hand, it could mean that you're testing "how" the unit is doing its job rather than what it is supposed to be accomplishing.