I could talk to you about Kent Beck or I could just give you the link to his website.
Now you can see I chose the option B.
This week I listened to Kent talk about testing in a way I never heard before.
Test Driven Development
- Write a unit test with the expected output, then
- Write the code
Very simple, right?
TDD is not for everyone. Some developers will find it really easy -that’s the case of Kent-, others won’t.
From Kent’s point of view Pro TDD:
Maybe I won’t know how to program something, but I’ll know how to test it…
I hope I’m not the only one, but sometimes I’d be coding, then stop and think “I have no idea how to solve this” or I just don’t know how to begin. TDD is really helpful in this situations, because after you write a test, at least you’ll know what are the inputs and outputs, and that’s a first step.
On the other hand, David Heinemeier talks about the struggles of TDD:
It’s unnatural to write a test first for each functionality.
I agree on this. I’ve done TDD a few times at school and… I forget. I would start with the correct flow: write test, code, test fails, code, test passes, repeat… Then, at some point I already programmed a bunch of functions and where are the tests? Well, I forgot to write them – or I pretend I did, but actually just got lazy -.
Test && commit || revert
Second, I listened to a podcast about Test && commit || revert (test and commit or revert, TCR). I’ll keep explaining using quotes. Not sorry.
If you can break it, then you have to be the one who fixes it.