Introduction
Putting the Three Rules of TDD Into Practice
Technology

Putting the Three Rules of TDD Into Practice

I've been thinking alot lately about how to practice better at software development. One of the things I want to get really good at is unit testing. I think unit testing is vital to the success of a software project. Good unit tests can reduce your overall debug time and can help give you confidence that your code changes aren't breaking anything. However, as anyone who has written more than four lines of code can attest to, writing unit tests is similar to eating vegetables or working out. You know it's good for you and can pay huge dividends in the future, yet we still don't do it.

So, the obvious question here is: if unit tests are so good, what is stopping us from writing them? Assuming that we can go ahead and agree to the assertion (see what I did there?) that unit tests are indeed helpful and worth writing (which is a controversial statement in itself), I think the main reason developers neglect writing tests is due to a lack of standardization. Developers just don't know where to get started sometimes. When do I write tests? How many tests do I write? When do I run my tests? What if I know a change works, do I write a test for it anyway?

This is where Uncle Bob's article can really help us out. Here, Uncle Bob outlines three very specific rules that can clear up any of the questions you may have been struggling with.

The Three Rules of TDD

  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
  3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

At first, trying to follow these rules is going to be pretty tough. Very tough actually. I'm still trying to get into the test-first mindset and it's going to be difficult to break away from all those years of doing development a specific way. However, I know that this is an area of development that I am weak in, and anything I can do to improve how well I write unit tests is welcome.

Ready to get started? Uncle Bob suggests checking out The Bowling Game Kata. Check it out and let me know what you think.

Robert Greiner
Author

Robert Greiner

Professional optimist. Passionate about cultivating high-performing teams @ scale by integrating the timeless wisdom of the past with the marvel of today's emergent technology in a practical way.

View Comments
Next Post

How to set a default browser when debugging in VisualStudio

Previous Post

Fixing the "TypeInitializationException was unhandled" exception

Subscribe for free

Subscribe to my newsletter and get the latest posts delivered right to your inbox for free. I don't spam and your email won't be shared with third-parties.

Thanks for subscribing!

Check your inbox to confirm your subscription.

Please enter a valid email address!