Fortsätt till huvudinnehåll

Insights from Kent Beck's "The Money Example"

A very well known book on Test-Driven Development (TDD) is Kent Beck's Test-Driven Development by Example. I have just read through the first part, The Money Example, and now I am following it by writing the code i C# (most parts translate directly from Java to C#).

One of the big insights I got from following Kent's thoughts is that a lot of effort should be put into the refactoring step. Kent quickly writes a small test followed by a simple implementation to make it pass, in many cases just returning a constant value. Then the big part of the work starts, making the application code generic and clean.

Refactoring the code involves removal of duplication. Here an important insight is that there might be duplication not only of code, but also of data. For example, assume that the test expects the value 10 to be returned by the application code. Hard coding the application code to return 10 is data duplication and must be removed in the refactoring step.

I believe that the insights above are key when practicing Test-Driven Development. You need to carefully refactor the code, both application- and test code in each TDD cycle and remove both code AND data duplication.

Kommentarer

Skicka en kommentar

Populära inlägg i den här bloggen

Does TDD really improve software quality?

I have asked myself this question several times, and searched for answers, without coming up with any clear answer. Therefore I have decided to go hard core TDD for a longer period of time (at least 6 months) to really evaluate the effects. There are several things that I find confusing when it comes to TDD. One example is what actually defines a unit test. What is a "unit" anyway? After reading a bit about it I found a text claiming that the "unit" is "a unit of work", i.e. something quite small. Like converting a string to UPPERCASE or splitting a string into an ['a','r', 'r', 'a', 'y'] of chars. This work is usually performed by a single call to a single method in a single, isolated, class. So, what does it mean that a class is isolated? Does it mean that it doesn't have any dependencies to other classes? NO! In the context of TDD it means that any dependencies are supplied by the test environment, for exa...
3 kommentarer
Läs mer

Codility tasks - Part I

I was recently faced with two codility tasks when applying for a job as an Embedded Software Engineer. For those of you who arn't familiar with Codility you can check out their website here:  www.codility.com Task one - Dominator The first task was called Dominator. The goal was to, given a std::vector of integers, find an integer that occurs in more than half of the positions in the vector. If no dominator was found -1 should be returned. My approach was to loop through the vector from the first to the last element, using a std::map to count the number of occurences of each integer. If the count ever reached above half the size of the vector I stopped and returned that integer and if I reached the end without finding a dominator I returned -1. So was that a good approach? Well, the reviewer at the company rated the solution as 'pretty ok'. His preferred solution was store the first integer in the array and set a counter to 1. Then loop through the remaining i...
7 kommentarer
Läs mer

Some links to look more at

This post is a "note to self" to look more into these links: https://blog.idrsolutions.com/2013/09/5-tools-to-help-you-write-better-java-code/ https://blog.idrsolutions.com/2014/06/java-performance-tuning-tools/ I am looking for tools for static code- and performance analysis on Java code.
6 kommentarer
Läs mer