Category Archives: Code Cast

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.

Read More →

TDD as if you Meant It: Refactor Primitives to Concepts (Episode 3)

TDD as if you Meant It: Refactor Primitives to Concepts (Episode 3)

About

Hidden Concepts

Each primitive is always hiding a business concept (or call them Domain Entities if you wish). During this episode these primitives will get better names (“Maximize Clarity” from the Four Elements of Simple Design) and when I see duplication between them, it will be removed (“Minimize Duplication” from the Four Elements of Simple Design).

Whenever these concepts remain hidden, the cost of change is big. The more hidden design concepts we have, the bigger the cost of change. I optimize my code for fast and cheap changeability. Because this example is written using Object Oriented Programming concepts, each of these concepts needs at the end to become a class.

Classical Evolutionary Design Layers

The business concepts grow in layers from: primitives, to variables, methods and then classes. With TDD as if you Meant It we always use the rule of three when evolving from one layer to another. I always use refactorings to make duplication explicit and then minimize it. I never skip a layer, because that would be a much too bigger step. We could call this approach Evolutionary Design in Baby Steps.

This approach is useful when starting bottom-up, when there are no, or not may classes and methods, but tests. This approach would not be suitable usually when having a top-down approach.

Read More →

TDD as if you Meant It: I care about Behavior and not about Representation (Episode 2)

TDD as if you Meant It: I care about Behavior and not about Representation (Episode 2)

About

Intentional Primitive Obsession

In the first episode I added some tests where I represent state as strings. This is an intentional approach to hide the complexity of the concepts with primitives. Since with TDD as if you Meant It I am not allowed to add any new classes, I need to start the problem by using primitives. I could have used an array to define the Board concept, but that already means that I am taking more complex design decisions.

Triangulating

I am focusing on triangulating on the concept of GameResult in order to have enough proof in order to extract it to a method. The typical proof I am searching for is duplication. I apply the Rule of Three to spot duplication and then to generalize my code.

Deductive vs Inductive

When doing evolutionary design I am deductive or inductive.
Inductive: I start from small concepts and I generalize them. Whenever I can can generalize some higher order concepts from the code I have, I extract them. These higher order concepts are usually a crystallization of the raw primitives.

Deductive: when doing design up-front I am deductive. I start from some bigger idea and then I try to prove it with code.
Read More →

TDD as if you Meant It: Think – Red – Green – Refactor (Episode 1)

TDD as if you Meant It: Think – Red – Green – Refactor (Episode 1)

About

TDD as if you meant it is a very strict way of writing code in a Test Driven Development approach. One needs to follow the rules below:

Guidelines

In the first episode the main focus in to respect a few guidelines:

  1. Guideline 1: Always start with outputs when doing an analysis
  2. Guideline 2: Behavior Slicing
  3. Guideline 3: SIMPLIFY!
  4. Guideline 4: Introduce only one notion (domain concept) at a time, one per test
  5. Guideline 5: The rule of three “only extract duplication when spotted at least three times”
  6. Guideline 6: Triangulation

Read More →

Legacy Coderetreat: Episode 13 – Document Possible Bugs with Tests – Codecast

Document Possible Bugs with Tests – Codecast

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Code Cast

This is a codecast in Java.

In the previous episodes we reach the moment when we extracted one simple class. We used the The Rule of Three and pure functions. This newly extracted class is covered with characterization tests. Then we wrote some unit tests in the following episode. But some of the behavious seemed strange, and we thought they might be bugs.

Because we are never sure when working on existing code if some behavior is a bug or a feature, we want to document all the suspicious cases. In order to do that, I am presenting three methods: use an annotation, prefix the test, use a different class.

Bug or feature? Check out the codecast to see all of them in action.

Read here more about this concept in my blog post.

When we document defects with tests it is a good idea to group all the tests documenting possible bugs one after the other. The discussions with the business persons are easier and you do not need to search the next test again and again.

Always discuss with business persons before changing the code. Often one might think they understand what the code does, but the situation if often very different in practice. Think to verify every detail with business analysts before changing the existing code.

Legacy Coderetreat: Episode 12 – Unit Testing on Legacy Code – Codecast

Unit Testing on Legacy Code – Codecast

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Codecast

This is a codecast in Java.

In the previous episodes we reach the moment when we extracted one simple class. We used the The Rule of Three and pure functions. This newly extracted class is covered with characterization tests. But that is not enough, we want to continue adding other types of tests to understand the system better.

This is why during this episode you will see how to add unit tests to code extracted from a legacy code class. These tests have a small granularity level than the characterization tests we already have. This is the moment to dive more into details.

See this video to understand how you can document the current state of the system, by unit testing on legacy code.

Read here more about this concept in my blog post.

We started with a class having non-public methods. The purpose of this session was to start covering the class with tests. In this moment we have short and clear unit tests, written in isolation of any slow dependencies. These tests are fast and we need to run then any time we will change the production code, to make sure we do not introduce defects.

In the same way as shown in the last blog posts, we can extract pure functions, extract classes and then cover these classes with unit tests.

Legacy Coderetreat: Episode 11 – Extract Class – Codecast

Extract Class – Codecast

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Code Cast

This is a code cast in Java.

In the previous episodes we restructured some parts of the code base. We also extracted pure functions and applied The Rule of Three when restructuring the code.

Because we have extracted some pure functions, now we need to think if those pure functions belong to new classes. So we structure the functions in a way that they belong together from the point of view of their responsibilities. After structuring the functions we extract the class.

Learn from this video how to extract a class in legacy code in such a way that you do not introduce side-effects to the existing behaviour.

Read here more about this concept in my blog post.

Legacy Coderetreat: Episode 10 – Refactoring the Rule of Three – Code Cast

Refactoring the Rule of Three – code cast

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Code Cast

This is a code cast in Java.

When refactoring legacy code we need to make sure the structures we extract have a correct meaning. This is why The Rule of Three is very useful: extract to a new structure only when you find an identical duplication three times. Usually we do not have identical duplication, so in that case we need to make the duplication clear, check that it exists three times and only after that perform the extraction.

This code cast will show you also when it is not a good idea to extract a new variable, even if you see it duplicated many times. This is a mechanical kind of refactoring, but reasoning is very important even when we want to get fast by getting mechanical refactorings into our tool bag.

Read here more about this concept in my blog post.

Legacy Coderetreat: Episode 9 – Extract Pure Functions – Code Cast

Extract Pure Functions – code cast

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Code Cast

This is a code cast in Java.

In the first episode we wrote some characterization tests with the purpose to create a basic safety net. Now we continue to refactor the code, starting from there. We already have some tests running and we want to have methods that do only one thing; we want to apply the Single Responsibility Principle. A really good tool that can help is using pure functions. We extract functions, make them static and then make sure the function does not have any side effects. These functions help me clean the code and help me start structurig the code according to clear responsibilities. At a later time we will extract all these functions that have similar responsibilities to a new class.

Read here more about this concept in my blog post.

 

Legacy Coderetreat: Episode 8 – Use Mocking Framework – Code Cast

Use Mocking Framework – code cast

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Code Cast

This is a code cast in Java.

In this code cast you can see how to start using mocking framework on an existing code base. Once we have an interface, we can start using the mocking framework to test external dependencies.

After extracting new and clear methods from the messy code and after extracting classes, we now have a code base with clearer dependencies. However, once we understood how to do dependency inversion, testing the core system becomes a bit more difficult. We need to write tests to show how the core system collaborates with the dependencies we inverted. For testing collaboration with inverted dependencies we use mocking framework.

Read here more about this concept in my blog post.