Tag Archives: Java

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 – Code Cast

Document Possible Bugs with Tests – 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 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 behaviours seemed strange, and we thought they might be bugs.

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

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

Read here more about this concept in my blog post.

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

Unit Testing on Legacy Code – 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 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.

Legacy Coderetreat: Episode 11 – Extract Class – Code Cast

Extract Class – 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 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.

 

Legacy Coderetreat: Episode 7 – Extract and Override – Code Cast

Extract and Override – 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.

Extract and Override is a very useful technique to break static dependencies. Whenever we cannot write tests for a piece of code, it is often because we have static dependencies. In the code cast below you can see how to use extract and override having a random number generator very tightly coupled. Because of that, we cannot have the same output for some clear steps. The solution found in this video is to extract the random to a new method and then override the random generator, just for tests. In this way we have predictability for tests.

Read here more about this concept in my blog post.