Mastering TDD

Two weeks ago I went to Paul Stringer's course "Mastering TDD/BDD in iOS". After the two days, I was exhausted. During the course, we looked at all the theory and completed some exercises. Paul gave us lots of links and books to read and, quite frankly, I was feeling overwhelmed. I saw myself in front of the computer, with all those links to follow and read, and I didn't know what to do, so I laid back in my chair and closed my eyes and thought — What do I know about TDD?

Following the Rules

Well, I know that it has laws:

• You must write a failing test before you write any production code.
• You must not write more of a test than is sufficient to fail or fail to compile.
• You must not write more production code than is sufficient to make the currently failing test pass.

I know I should follow the circle Red - Green - Refactoring:

• Red - Create a failing test
• Green - Write enough code to make the test pass
• Refactor - Clean up your code and your tests (don't forget that your tests are code too)

This works well to enforce the three laws of TDD. And as Kent Beck said:

Make it work. Make it right. Make it fast.

If you want to know all about the cycles of TDD, here is an excellent article by Uncle Bob.

Going to Your Favorite School

And there are schools…well, not physical ones:

• The Detroit/Chicago School or the Classicist approach
• And the London School or the Mockist approach.

The first one uses real objects/classes and it tests the state of those objects. The second tests collaboration between objects and for that it uses mocks. You have this article by Sandro Mancuso and this other by Jonathan Rasmusson that can help you distinguish them better.

Knowing Your Friends

As an iOS developer, I tend to be more of a mockist since I drive my tests from the UI. And developing an app in Swift has some challenging aspects since we don't have a Mocking framework. We do it all "by hand," so, yes, knowing very well what kind of test double you need is a good thing. People tend to call them all mocks but as Martin Fowler said here:

Mocks aren't stubs

But if you still have doubts about test doubles, this excellent article by Uncle Bob will definitely shed a light on it (and I even found a version for Swift here). Magical!

Setting Your Priorities

Yes, that's a really important one: Use the Transformation Priority Premise to avoid big steps and to guide you into the generalization of your code. As Uncle Bob said:

...Refactorings have counterparts called Transformations. Refactorings are simple operations that change the structure of code without changing its behavior. Transformations are simple operations that change the behavior of code.

Another good article is this one by Pedro Santos. Don't forget that during the refactor phase your design skills are put to test, as Sandro Mancuso said here:

TDD is not a design tool. It’s a software development workflow that prompts for code improvement in its lifecycle... The great thing about TDD is that it is constantly asking us “Hey, can you make your code better? See how hard testing this class is becoming? OK, you made it work. Here’s your green bar. Now make it better.”

Having Good Habits

TDD must be approached like a discipline. You must have good habits to stick with it. Here is the TDD good habits manifesto. This came up for the first time in SoCraTes UK ‘16 in a form of a session facilitated by Mani Sarkar and Pedro Santos, where they challenged us to add or remove practices to their original draft that you can see here.

Conclusion

Well, it seems that I have a minimum knowledge about TDD. I still need to practice a lot, and apply what I have learned when coding. Here are some books that you could read:

• Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce.
• Refactoring: Improving the Design of Existing Code by Martin Fowler.
• ATDD by Example: A Practical Guide to Acceptance Test-Driven Development by Markus Gärtner.
• Test Driven Development by Kent Beck.
• Working Effectively with Legacy Code by Michael Feathers.

This article was first published on my personal blog.