Test Driving Your Code
You need to fail to succeed. This rings true with many things (or at least I keep telling myself that to feel better), but especially in test-driven development.
How do you do this, you ask? Well, let me demonstrate!
- Write out tests before you write out any features.
WAT!? This don't make no sense. Won't my test fail?
Just wait, grasshopper. This may sound like backwards logic to some, because if you write specs without features, those specs will obviously fail. What this does is causes you to think about the requirements necessary to execute the applications features. You write that test to inevitably fail, and if it doesn't, there's something wrong with that spec.
- Write the code for the feature to pass the test.
Uh, ok. Why wouldn't I just write that in the first place?
By honing in on writing just enough to pass that test, that creates simple and concise code. You learn to live by KISS. Not kissing, you crazy people! Keep It Simple, Stupid.
Some might combat test-driven development by saying it takes too long or their code isn't worth testing. We stand behind the principle that if you're writing good code, it's worth testing. And if it's not worth testing, then why are you writing it?
Could you put your job behind your code? I know that I could.