TDD as a Roleplay
Have you ever heard about TDD? According to Wikipedia, Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only.
TDD’s most famous buzzword is “Red-Green-Refactor”, it’s because that TDD’s main flow is just like that. Red means you create a single specific test, then you make it Green which means create the minimum code to make the test pass. When we successfully pass the test then we need to clean up our growing codebase by refactoring it without breaking any test.
How can we create a test for something that doesn’t exist?
This question is a common question when someone starts to learn about TDD. I think we shouldn’t think about it as a test, it should be a specification. When we think of it as a specification then it will become more clear because the definition of the specification is “An act of identifying something precisely or of stating a precise requirement.”. I suspect this is why in ruby the test is called spec.
The TDD Roleplay
Doing TDD is like playing a role-playing game. There are three roles here, the first one is a short-minded but persistent manager, the second one is the lazy programmer, the last one is a timid but tidy programmer.
The manager creates a really specific and small specification. He/She just creates a single specification at a time, he doesn’t think much about the future specification. But after the previous specification is done, another one is created, he/she keep creating a new specification to improve the system. This is the representation of Red, the test that fails.
The lazy programmer doesn’t want to spend much time coding but he/she need to complete the specification from the manager. The lazy programmer will always do the minimum amount of code just to pass the specification from the manager, he doesn’t wanna code more than that. This is the representation of Green, the code that passes.
The timid but tidy programmer always feels afraid, that’s why he/she never going to break any previous specification, but he cares so much about code cleanliness. This person always tries to clean up any mess that he/she found in the codebase while making that no test is broken. This is the representation of Refactor, the code cleaner.
Doing a TDD mean you need to become the right person in the right time, when you create test you should be the manager that focuses on the specification, when you do the code you should be the lazy programmer, when you do the refactor you should be as tidy and timid as the last person did. Remember this and you will do your TDD well (and DnD too).
Call to action: If you‘ve enjoyed this article, please do two things to help others find it: share it and recommend it 👏
