Monthly Archives: September 2017

You are browsing the site archives by month.

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.

 

Read More →

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.

Read More →

Talk: Behind Agile Practices (RO)

Talk: Behind Agile Practices (RO)

About

I gave this talk about Agile Practices at the Bucharest Agile Software Meetup Group, Agileworks. It’s in Romanian, because that’s what the audience wanted.

One by one I explain how some of the most common agile practices emerged. Also I explain when and why it’s a good idea to apply them. As seen in practice, some practices are just a hype, and they are very difficult to implement in an organization. Due to that you should always take into account the negative impact of introducing a new practice. Also be prepared for the consequences. There is no such thing as a perfect practice, you can always generate negative effects.

Agile started to become a hype because more and more companies are forced to deliver software faster. Because the markets are changing faster, the production and delivery speed is essential in this fast-paced world.

The last topic I am addressing is the apparent need or organizations to scale agile. There are multiple ways of scaling agile (horizontal, vertical, etc). Most of all we must ask ourselves if we really need to scale. Scaling agile too fast may generate counter-effects. Probably the worst effects are the decrease in productivity and minimizing the focus on the product value. Finally we can scale an organization and focus on the agile format, but not on its values.

Best Practices Read More →

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 →