TDD: Prove what you know

Accepting the concept of TDD (and yes I mean test FIRST development) was a tough task for me. At first I didn't understand the complete benefit, honestly I can't admit that I do completely now. But I've come around none the less.

When working on a project it is pretty much impossible to deliver code without having a bit of an understanding of what it is the end result of that code execution should be. The user doesn't care about implementation. All the end user knows is that when they submit this data in that field then something specific had better happen as a result. I didn't really grasp how that was a reflection of what test first meant.

Now I like to think of the end user and my unit test as the same thing. Both are simply executors of my code. I can't know what the system is supposed to do unless the end user tells me so. At first that was all I saw. The user says so and then I code the implementation, then add some tests. Now I see that if the user tells me what the requirement should result in I replicate that in a test, and that proves without a doubt that I understand the requirement. If you don't understand it enough to write a test for it then you sure as heck don't know enough to write code to implement the requirement.

Not only does this help you better grasp the requirement before diving head first into coding, it also gives you an upfront contract that is based on vernacular communication. That adds a quality check. If you write the test first based on what you understand the requirement to demand then you write the code to satisfy that test and hopefully you don't write any code outside that (unless necessary, remember to use your head but remember to prove any code changes with tests for quality assurance).

So as long as it's sane I'd like to set a rule for myself for future coding:

If I don't understand enough of what is required in order to write a test
then I don't understand enough to code period.

Keep me accountable.
Until next time
Les