Leandro Boffi. Cloud, Identity, Mobility and Software Architecture.

Test-Driven Development (TDD) is an advanced development technique that propose to write automated tests before functionality implementation. Notice I’ve written”development technique” and not “testing technique”, one of the most common mistakes that people made is to believe that TDD is about testing.

In my opinion the main goals of TDD are to provide a little of certainty to one so uncertain task like software development it’s and also to impulse continuous improvement.

TDD is easy to adopt and I think that it’s an invaluable tool that every single developer should use. TDD allows me to sleep better at night, because I know that my code works, and I can prove it with a simple button click.

It also allows me to improve the design of my existing code without fear of breaking functionality inadvertently because, as I said before, I’ve got the power of prove that my code works by clicking a button. This is what I mean when I say certainty.

Did I convince you to start with TDD? This is the first you must know, this are the two simple rules of TDD, quote from Kent Beck’s book Test-Driven Development: by example.

• Never write a singe line of code unless you have a failing automated test.
• Eliminate duplication.

Let’s start with the first one.

Never write a singe line of code unless you have a failing automated test

You sits facing your monitor and you have to write some code. Why? because you have a requirement, If you didn’t have one, probably you’d be reading this blog or using facebook.

Each time we have to write code is because we have a requirement to fit, what TDD says is: before you write the code to fit it, create a new test method to test it and do this for each requirement you going to fit. Run your tests, they will fail, this means that you didn’t fit the requirement yet, and just now you are enabled to implement your code.

The requirement is completed when your test/s pass.

One thing I learned from James W. Newkirk and Alexei A. Voronstov’s book, Test-Driven Development in Microsoft .NET is the fact of TDD is not about unit testing alone. There is other kind of test to specify customer requirements, commonly called functional or integration tests (but let this to another post).

Eliminate duplication (from XP rule: “Once and only once”)

Duplication is the common characteristic of bad designs. So after you made your tests pass, refactor your code to eliminate duplication. This is one of the keys of TDD, you can improve your code and design without fear of breaking functionality inadvertently.

This is why TDD helps to continuous improvement.

Red, Green, Refactor

Summarizing this is the flow you should follow when working with TDD (from the Extreme Programming Explored book) :

Final tips

• Work in what I call “baby steps”, small test, small pieces of code, remember if you want to be an agile developer your work should be iterative and incremental.

• Keep It Simple. Fit only the requirements you need to fit, no more, no less.

• Use mocking frameworks like moq to mock pieces of code that you don’t want to test.

• Follow the single responsibility principle.

Hope you find this helpful!