Category Archives: Code Cast

TDD as if you Meant It: Separate Production from Test Code (Episode 12)

About

When using TDD as if you Meant It we need to have a clear distinction between the test code, and the production code written in the test methods and classes. The more we dissociate the two, the clearer both production code and test code look. During this episode I made the final steps to separate production from test code. This is a final step of the triangulation of a specific concept.

Triangulation

When I started triangulating on the concept of Game, I made an analysis on inputs and outputs (called Behavior Slicing and explained in Episode 1), that lead me to write enough tests to be able to understand it. By triangulation in this case I mean adding enough tests to understand the links between the design entities. In some cases I need more tests, in others just a few. And of course the number of needed tests depends also on the experience of the coder.

Separation

When separating the two, we need to make sure everything is clear from any point of view: class names, package names, code structure in the IDE, etc. The code at the end of the separation needs to look as if we wrote it in a separate way all along. Whether we apply traditional TDD (where we write the test code in a separate file from the production code from the beginning), or we apply TDD as if you Meant It, the code structure needs to look the same. Of course, the design will be very different in many occasions because with TDD as if you Meant It we can zoom more on the simplest design possible.

Next step?

After this whole process of Behavior slicing to refactoring (Episode 3, Episode 4, Episode 5), to clean-up and to extracting production code I need to identify the next design concept to triangulate to. So stay tuned to see the whole TDD as if you Meant It process all over again, but with another concept related to the Game.

TDD as if you Meant It: Refactor and Clean-Up (Episode 11)

About

Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior

So clearly not any change in the code is refactoring.

During the last few episodes I extracted many design elements from the initial primitives, and this was refactoring.

Refactoring is different than clean-up. When cleaning I care about Clean Code, Coding Standards, Clarity, etc. Refactoring is difficult to make when I don’t have Coding Standards, because the duplication is more difficult to spot.

So my recommendation is

Every once in a while clean-up the code so that you can refactor your design easier!

Refactoring

The refactoring approach during this episode is mainly focused on design. There are many reasons to do refactoring: improve clarity, design, minimize defects, exploring alternatives, etc. These are the final stages in the TDD as if you Meant It cycle, when the design elements are almost ready to be separated completely from the tests.

Clean-Up

Cleaning up is important every once in a while. Without a clean code we cannot focus on the essentials, because there is too much mess. By clean-up I mean deleting the unused methods, delete the useless comments that initially were important, having the same structure in the same place, etc.

I really like having classes look the same: constants at the top, fields, constructor, public methods, private methods. And also having always the same spacing between methods, parameters, etc. All these have to do with the coding standards I use.

Coding standards are useful because they let me focus on what I need to refactor. I can easier see duplication between classes if they are structured the same.

About

The second episode of this #RemotePairProgramming series is about Strong Style Pairing. My coding pairing partner this episode is Llewellyn Falco.

Strong Style Pairing

The Driver is just the typist of the Navigator

Pair-programming is a technique where two programmers stay at the same computer and code together on the same problem. We have two roles: Driver and Navigator.

Driver = the partner who writes the code, and focuses on small details, on short term.

Navigator = the partner who understands what the driver writes and focuses on long term decisions. Typically the navigator’s focus is around the design, architecture concerns, clarity, conceptual cohesion, etc.

During a session of strong style pairing, the Navigator will take all the decisions. The Driver focuses on the small details, just to do what the Navigator has in mind. If something is unclear the two have a dialogue. The same as with traditional style pairing, both roles have the same focus: try to solve the problem as fast as they can with the highest quality possible.

About

During the first episode of this series I added some initial tests where I didn’t cover all the cases. Now it’s the moment to run coverage on the code and check the areas where I am missing tests.

My intention was to show you how to fix such a branch that was not covered by tests in the beginning. We can add missing tests even a lot later. So my mistake was intentional, because it’s a mistake I see very often and I wanted to show you what I do in this context.

Code Coverage with Tests

After extracting many classes and methods, I ca use code coverage to see which line(s) of code are not covered by tests. But code coverage is complicated. There are many types of code coverage:

Statement

Condition

Line

Method

Class

… and even more

So when you focus only on a metric, like code coverage, you need to know what to expect. You can read more at ISTQB.

Fallacies of Code Coverage

Let’s say we have the most complicated code in the world, and we want to have 100% code coverage:

1

2

3

4

publicvoidadd(inta,intb){

// I'm adding only positive numbers here!

returnMath.abs(a)+Math.abs(b);

}

If I add the test

1

2

3

publicvoidtestAddition(){

assertEquals(3,add(1,2));

}

then I will have 100% line coverage and 100% statement coverage. So then I’m done. I have added all the tests, right?!

But if then I add the test

1

2

3

publicvoidtestNegativeAddition(){

assertEquals(-4,assertEquals(-1,-3));

}

it will surely fail.

So take care when you use code coverage as a metric, it can trick you into thinking you added all the necessary tests, but if fact you have many missing tests.

TDD as if you Meant it and Full Test Coverage

TDD as if you Meant It doesn’t guarantee full test coverage, you need to have tools and use them to check your work

You can have full test coverage, but you need to have in mind some good practices:

Ask yourself when adding each test if you covered everything

When you have second logical flows (if, while, for, etc) always check really well if you added all the needed tests

Use a code coverage tool to tell you which branch is covered by tests

So the technique of TDD as if you Meant It will give you the context of having full test coverage, but you need to take the necessary measures to make sure.

Prize for Pawel

Even from the first episode Pawel Duda told me that I forgot to add a test for the “nobody won” branch. And he was right, I didn’t add the test with the purpose of adding it a lot later and show you how I do this. So when we meet he will receive a prize from me.

About

This is the first episode of a series of codecasts where I will explore, together with a remote (duh!) pairing partner, what remote pair-programming is. It is also about pair-programming techniques, and how they help us, or not.

Traditional Style Pairing

Two people stay on the same computer and code, for a specific problem.

But it is more than that. We have two roles: driver and navigator.

Driver = the partner who writes the code, and focuses on small details, on short term.

Navigator = the partner who understands what the driver writes and focuses on long term decisions. Typically the navigator’s focus is around the design, architecture concerns, clarity, conceptual cohesion, etc.

During a session of traditional style pairing the roles can stay the same, or they can change. But both roles have the same focus: try to solve the problem as fast as they can with the highest quality possible.

TDD as if you Meant It: Experiment Design Alternatives when Stuck (Episode 9)

About

During this episode you will see how I formulate experiments to decide where it is a good idea to get the design.

Refactoring

Evolutionary Design happens during refactoring. This episode is just refactoring, but with a clear purpose. The purpose is to identify, with a clear hypothesis, if a certain design solution would be suitable. The word suitable is very unclear, so when formulating the experiment I want to make my expectations very explicit.

There are many reasons to do refactoring. During this episode you will see a refactoring that is focused on discovering (one of) the correct ways to create the design entities.

Experiments

When I formulate my experiments I take the following steps:

Define the hypothesis

What would be good if this experiment succeeds

What would be bad if this experiment succeeds

Experiment example

Hypothesis: “two by two”, “one by one” should be a class “BoardStructure”

Plus
No more primitives about BoardStructure in the tests
All the structure will be in one place. Structural coherence.
Some coupling is expected from the tests, but only one other class will use boardStructure
Duplication will be removed in-between tests
Clarity will be better because a cohesive design structure is extracted

Minus
Increased code complexity, because of a new design element

After the experiment

If the experiment succeeds, I can take the decision to keep the changes, but only if I am sure I don’t need more proof. And it’s not about lying to myself that the solution is ok. I really need to be honest to myself and if there’s the least doubt, I need to go back, revert the changes and try again by adding more tests.

If the experiment fails, I note down the situation and the solution. Either in my head, or I document it somewhere. It is important not to try it again in that context, because it would be waste.

I learn a lot more from failed experiments. I understand which are the solutions I should never chose and the solutions that work only in certain situations. If you don’t have at least a few failing experiments it means you are lying to yourself that you found the correct solution from the beginning.

TDD as if you Meant It: Create Duplication in order to remove it (Episode 8)

About

After a couple of episodes when I showed how we can get out of TDD as if you Meant It to Traditional TDD. By Traditional TDD, I mean the TDD when you are allowed to create classes and methods before the test.

During this episode you will see how I focus on other primitives from the tests, and I add new tests in order to create duplication between the existing tests and the new tests. Then I remove the duplication by following the Rule of Three.

Duplication

Duplication can be of many types, but that is a different topic that I will follow later. During this episode I am focusing on structural duplication, meaning on the string primitives that still exist in the tests.

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.

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 fluentbuilder. 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.

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.

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.