Skip to content
Remote Live Coding with Grenoble TDD as if you Meant It

TDD as if you Meant It: Remote Live Coding with Grenoble (Episode 15)

TDD as if you Meant It: Remote Live Coding with Grenoble (Episode 15)

About

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.

Debriefing

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.

Refactor but in small steps now TDD

TDD as if you Meant It: Refactor, but in Small Steps Now (Episode 14)

TDD as if you Meant It: Refactor, but in Small Steps Now (Episode 14)

About

After in the previous episode I took too bigger steps, during this episode I start all over and take smaller steps. The main differences are:

  • I’m not getting that far, but I have a stable point of stop, compared to the last episode when the last point of stop was resetting all the changes.
  • During the process I don’t feel so unclear, the points when I stop because I don’t know what to do are shorter
  • I feel flow, the next steps are obvious
  • While coding I am happier I know where I am going
  • For the next episode I know where I need to continue from.
Some Traditional TDD part 2

TDD as if you Meant It: Some Traditional TDD – part 2 (Episode 7)

TDD as if you Meant It: Some Traditional TDD – part 2 (Episode 7)

About

This is the second episode of an alternative evolutionary design approach. During the (Episode 5) I refactored the code to generate a builder. The alternative presented in Episode 6 and 7 is to stop using TDD as if you Meant It for a while and start using some traditional TDD.

Focus on the Problem

During this second episode for creating the builder with traditional TDD, I am trying to focus on finishing the problem. This means I am trying to get in a flow state, where everything works well at the end. Also that means that I am often taking bigger steps than what you saw in the first 5 episodes. This is because I consider the risk being smaller, and because I know where I want to get.

Refactoring

Because I am focusing on the problem, I am doing more refactoring. And the type of refactoring is faster, in bigger and more direct steps. I want to leave a nice code base behind so I try to have the best code I can for the moment. So then during the next episode I can use this code with ease.

Scale of Evolutionary Design

At one extreme I am in the point where I know exactly what I need. In this case any form of Evolutionary Design or TDD is useless. I might want to add automated tests (while adding the code or after) to perform the checks on the code just for regressions.
At another extreme I don’t know at all what I need, but I have the specs. So I start with them and I focus on the principles of refining the code concepts in order to extract the appropriate design entities.

During this codecast I will situate myself very close to the extreme where I know pretty well what I want. But careful to be sure you always introspect and clarify if you have all the information to take a design decision without enough proof. Your solution might be too complicated or just inappropriate.

Some traditional TDD part 1

TDD as if you Meant It: Some Traditional TDD – part 1 (Episode 6)

TDD as if you Meant It: Some Traditional TDD – part 1 (Episode 6)

About

This is the first episode of an alternative evolutionary design approach. During the last episode (Episode 5) I refactored the code to generate a builder. The alternative presented in Episode 6 and 7 is to stop using TDD as if you Meant It for a while and start using some traditional TDD.

Traditional TDD

In a traditional TDD approach I am creating some structures up-front. I can create more or less design up-front, but still the minimum I create is the production class or function I want to test. This approach is different from TDD as if you Meant It where I am extracting the code from the test method, to the test class and to a production class.
In a traditional TDD approach we can have different approaches: bottom-up, top-down, middle-top, middle-bottom, etc. But I take this decision depending on the clear need I observe in the current moment.

Specifications with TDD

Whenever I start with traditional TDD, I need to define the clear specifications. Or in other terms, I define the clear needs of the design structure I need to add. In this current case I defined the fact that I need a fluent builder. So my current tests will reflect the need in the tests. In this approach the evolutionary part of the design is marginal. As I am very clear with what I need, I don’t need a lot of proof. This is not always the case.

Scale of Evolutionary Design

At one extreme I am in the point where I know exactly what I need. In this case any form of Evolutionary Design or TDD is useless. I might want to add automated tests (while adding the code or after) to perform the checks on the code just for regressions.
At another extreme I don’t know at all what I need, but I have the specs. So I start with them and I focus on the principles of refining the code concepts in order to extract the appropriate design entities.

During this codecast I will situate myself very close to the extreme where I know pretty well what I want. But careful to be sure you always introspect and clarify if you have all the information to take a design decision without enough proof. Your solution might be too complicated or just inappropriate.

 

Refactoring to builder tdd

TDD as if you Meant It: Refactoring to Builder (Episode 5)

TDD as if you Meant It: Refactoring to Builder (Episode 5)

About

Cost of Change during evolution

There are some language structures that make Evolutionary Design difficult. One of them is the constructor. When I evolve the code, I often understand that one more parameter is needed for the constructor. Because of this I need to minimize the cost of change of the constructor. The best way I know to do that is by creating a builder. In this way I will call the constructor only once, in the builder. So my cost of change is really small.

Duplication

If I need to introduce a new design concept, I make sure before that I minimized the duplication connected to that new design concept. Calling new Board(…) many times is a clear sign of duplication. This duplication would make the code evolution considerably slower.

State Immutability

Testing becomes easier when state does not change during the life cycle of the object. Or, there are no setters on any object. That is why I use constructors and private fields.

Fluent Builder

A builder is called fluent when it looks like playerBuilder.withName(“Adi”).withAge(7).withColor(“Red”).build(). If let’s say I need to introduce a new characteristic to my player, I can always add a new method to the PlayerBuilder. And I would have something like playerBuilder.withName(“Adi”).withAge(7).withColor(“Red”).withExperienceLevel(“Beginner”).build().

Focused Tests with Idempotence

Having this type of builder also lets me have focused tests. I don’t want my test that needs only Age to contain Name. So I want to be able to have playerBuilder.withAge(34).build(). In this case all the values for all the other fields of Player will have a default value that is not generating any side-effects in the system. We could call this characteristic an idempotence of the builder.

Refactor to a new class TDD

TDD as if you Meant It: Refactor to a new Class (Episode 4)

TDD as if you Meant It: Refactor to a new Class (Episode 4)

About

Extract Class

Starting from the methods that I extracted in the testing class I make them static and then extract them to a new class. The methods from the extracted class are then static. I change the static call with a call to an instance created in the setup of the test. There is a small trick I use when doing that, so that I am always on green while refactoring. Check the codecast to spot it!

The Rule of Three – extract class

In this case as well The Rule of Three applies: only extract duplication when spotted at least three times. When extracting methods to a new class I need at least three methods that belong together.

As mentioned in the previous articles, this is just a guideline. If you are sure, extremely sure, that one method should be extracted, then go for it. But be careful not to generalize to soon. Premature generalization is the root of all evil (Donald Knuth paraphrase).

Testability – Guidelines

Because all the tests are calling the extracted class, it is tested as well, but indirectly. This is a classicist TDD approach where I don’t mind if I test a few classes together, without any dependency injection, stubbing or mocking. Another approach would be to start adding tests to the extracted class, after it was extracted. It is a question of style, but there are also some guidelines to this.
The extracted class needs to either have only logic, or only to hold data.
Whenever I don’t have any logic in the extracted class, I won’t add new tests.
If the extracted class has logic, but it is trivial, I will use the existing indirect tests.
If the extracted class has a lot of logic, I will split the existing tests to have specific tests for the extracted class, and smaller (simpler) initial tests.