TDD as if you Meant It: Remote Live Coding with Grenoble (Episode 15)
At SoCraTes France I paired with Rémy and Johan to show them how I code using TDD as if you Meant It. We had a few hours to try it, and then Rémy told me he would like me to present this to the Grenoble Software community. So this is how we arranged a remote live coding session on TDD as if you Meant It.
During this session I am using Poker Hands as a problem, and I start with the usual Think-Red-Green-Refactor and Behavior Slicing. Then a lot of refactoring is going on. I invite you to watch the video and come with questions and improvement ideas.
At the end of the remote live coding session we had a remote discussion about what happened. Here is in form of Q&A.
Question: When you want to show the duplication to be sure it is not accidental, you try to duplicate three times the same code. Do we need to do this when we do just copy/paste? It doesn’t really help the tests.
Answer: The fact that you can duplicate the test it shows it is easy enough and we don’t necessarily use the Rule of Three. But there are other cases when it’s more complicated and just duplicating the tests would not show the same. And there is still some duplication that doesn’t prove in the production code. We find that it’s not really the same behavior, and it’s often a surprise. The fact that I can make the duplication the third time is just making the point that we need to remove the duplication. Otherwise I need to search for duplication in another way.
Question: It seems that we create these tests just to follow the Rule of Three, not because we want to.
Answer: I don’t want to create the tests just to follow the constraint of The Rule of Three, I just want to be sure enough that what I am doing is on the good path. I don’t want to rush into refactoring. It is a question of how well you know your domain and how much you trust your instincts. The TDD as if you Meant It comes with the idea you don’t trust your instincts and you need proof.
Question: If you want to create some duplication, we can use parametrized tests.
Answer: Yes, for the tests that are duplicated we can use parametrized tests and compress the code. And probably at the end there will be very little code.
Question: Have you detected different styles of doing TDD
Answer: Yes, but most of the problems I see that people fail to respect the rules and don’t find a way to respect the rules. But of course, there are very different styles. Some go very functional, some like to use more state, I go in very small steps. I like to go in very small steps and focus on triangulation. I like to use it as a machine that is generating duplication in all these tests and then because I have duplication, I extract the methods and the classes. You do need to refactor a lot. And you need very good tools to refactor automatically.
Question: I think this technique is a lot more difficult to use with Legacy Code, is it?
Answer: Yes, it is more difficult. But you don’t need to use it too often with legacy code. I can use it on legacy code, but first of all I surround the code I want to change, put some interfaces around it, and then use the same steps to generate the code to rewrite it with very small steps in a simpler way. There might be situations where I prefer to rewrite some legacy code instead of refactoring. When using TDD as if you Meant It with legacy code you need to take very small steps, and do a lot of refactoring in small steps, understand the flow of dependency injection and understand the patterns. All these I learned by using TDD as if you Meant it a lot. I think it helps you to refactor better. You have this refactoring muscle. With legacy code you have a lot of primitives and so much misplaced code. Here with new code you have the same, and you need to understand how it makes sense to put it together. So I think you can use TDD as if you Meant It especially for the refactoring part.
Check the video below with the codecast with remote live coding:
- It would be interesting to go deeper in the code. We saw the start, but we need more to understand if we can use this in production. I don’t know if the design we created so far is the best.
- The purpose of this way of writing code is to go in small steps to avoid making mistakes. If you know your way, this kind of approach is not the best. But when you don’t know exactly where to go, this kind of approach is very useful. You can understand the flow of objects and where to do dependency inversion and even spot design patterns or how to make the design use SOLID Principles.
- This technique helps you with smaller steps.
- I do generate a lot of duplication in the production code and then reshape it, not necessarily using TDD as if you Meant It.
- The new thing to me is that we postponed the decision of creating the data structure.
- What I like with this method is that we need the proof that we don’t have accidental duplication; we need to do refactoring and to take small steps.
- It’s not just from these constraints that we have the best code, but we need more.
- I like the idea, but I’m not ready to use it whenever I want.
- When you use static to see if you have a pure function is not just to use the IDE for automatic refactoring, but to have proof we have a pure function.
Check the next episode on TDD as if you Meant it here: http://blog.adrianbolboaca.ro/evolutionary-design
On the same page you can find more ideas on Evolutionary Design.
Many thanks to Keith Braithwaite for creating the concept of TDD as if you Meant It
Teddy bear thanks to Erik Talboom for all the pairing, discussions that lead to so many twists we discovered together with TDD as if you Meant It.
Special regards to JB Rainsberger for the fun pairing we did using TDD as if you Meant It