Tests and the Red | Green | Blue cycle put pressure on your design all the time as you code. Your design decisions are guided by that pressure.
As Corey Haines once stated: "It's like having a little buddy as you code, helping you along, pointing things out such as when your design sucks, when you've broken something, etc."
- forces you to only create enough code to make a test pass (you’re keeping lean all the time)
- you won’t be able to write the next test if you have code that’s too coupled
- you’ll know immediately when you’ve broken behavior. This is different than test after.
- With TDD you know that what you've broken is only a very recent change you just made a moment ago (less time hunting, fix it quick and move on).
- With test after, you have to hunt for that issue that broke your code
- you’re thinking about design in very small steps instead of trying to wam bam code the core of the logic at
once or trying to code many things at once which your mind can easily get tangled up in.
- TDD keeps your mind clear on the current behavior you’re writing for, and you don’t think beyond that much at a given moment
- it forces you to refactor little bits all the time. Code is constantly being refactored, next test relies on previous refactoring and so on. By refactoring and by having design pressure forcing you to decoupled and modularize your code, the experience is much more smooth and straight forward as you design
- you know that what you just designed works. Every TDD loop starts with a failing test, so you’re proving the code works NOW, not later..and proving it now provides you a tight feedback loop all the time letting you know when your code sucks, when you’ve broken something, etc.
With test after, you get NONE of the above. And it's all manual, time consuming, and it's too late if your design sucks.
You might feel faster because you just banged out code, but you get no benefit from it other than “hey I whipped it out yay!” but you don't have confidence that QA won't find a ton of bugs even if you've done manual testing.
And Manual Testing. Manual Testing! aren't you tired of that????
- it’s all manual testing (console.logs, firing up the browser every few minutes….that’s SLOW), rush to code a bunch of shit and then you realize later (You find out oh…I can’t test it easy now because things aren’t as modularized as I thought
- you have no coverage
- so I have no confidence that anything works or when I refactor if I've broken anything.
- I guess we'll pray QA doesn't find something again after I MANUALLY test my changes again)
- my design sucks! No it really sucks! we were in a rush OR "We Said we'd refactor, but no time again, design still sucks"
- now I feel like I have a big heavy gorrilla on my shoulder’s because I'm going to promise myself to refactor and add tests…which never happens
- With TDD, your code is already lean and decoupled, because you were forced to do that in the first place
- how can I prove my stuff works and isn’t broken at any given moment?
- If you don’t have tests to prove it works and those tests are reliable and you’re able to add tests easily you’re left with …well, firing up the browser or running the backend API manually
- With TDD you can prove stuff works all the time, at any give moment in just a few seconds (run all tests)
- bad code slows you down like a motha
Test after sucks, you don’t have these issues when you TDD. And until you try TDD, you won't understand that.
Upshot: TDD gives you a sane codebase to code in because it forces you to design cleaner, more modular, and lean. And you're doing this in manageable steps that are short lived
Upshot: you go home knowing you have well tested, cleaner, leaner code with less bugs
That's about as best as I can describe. Now it's on you to truly try it out and see for yourself!
Which would you prefer, test after still? After you try TDD for a while you'll never go back to test after.