Sunday, November 1, 2009

Too much OO as a result of TDD?

I was directed to this interesting article about Object-oriented (OO) creates complexity. The author is building a snakes and ladders game with someone who is new to Test-Driven Development (TDD). The author and his developer came up with 6 objects i.e. Game, Board, Player, Dice, Snake, Ladder. Another developer happened to pass by them and thought they were wasting time on creating those objects. After 15 minutes of discussion, they came up with the following approach (quoted directly from the article):
  • one class called Game (place holder, the class is not really required) with one method called move(int number_on_the_dice)
  • a list to hold the current position of each player on the board (there can be more than 2 players)
  • a hashmap with starting and ending points on the board (represents both the snakes and ladders, how does it matter whether its a snake or a ladder, they are just starting and ending points on the board)
  • a counter to calculate player’s turn
  • and … and what? …that’s it
I could not help wondering what went wrong. Then it strikes me that I may end up with the similar approach if I chose to use TDD. For example, I will use ladder and snake objects to keep track of the starting and ending point for ladder and snake, respectively. There will be more than one snake and ladder on a board. So, I will end up shoveling them into a container, too. What is interesting about the snake and ladder objects is they both have the same attributes i.e. starting and ending point. If I am using the TDD approach, this will be revealed to me right away and I need to question my approach.

TDD is not only about testing and design. TDD suppose to help us to uncover the unexpected so that we can make the necessary trade-off in our design. We should not just focus on creating objects or tests during TDD. We should pay attention to the signs in our code, which we call code smell. For example, if our ladder and snake objects have the same attributes (starting and ending point), we should pause and think a little bit. It seems like we have code duplication in different objects. It is no different than having similar code in two different methods. We should strive to eliminate code duplication. But, before we do that, we need to ask ourselves a few questions:
  1. Will the additional object help to communicate the domain concept better to the next developer?
  2. Will the additional object help to communicate the domain concept better to the business user?
  3. Is the domain concept complex enough to warrant a separate domain object?
  4. Is there a hidden domain concept that can represent both snake and ladder domain concepts?
After we understand the trade-offs, then we refactor our code. So, it is not TDD that introduces object complexity. It is us who often miss the forest for the trees.

Thursday, October 15, 2009

Test-Driven Design

Venkat wrote a nice article on when to use mock. He made a point that by gaining deeper realization on domain problem, we can make our design simpler. As a result, we will not need a mock object. I feel that the role of Test-Driven Development (TDD) as a design tool deserves more attention. This is the most misunderstood part of TDD. Many people think that TDD is about writing test. But, it s more than just testing. We are also designing our application at the same time. I prefer the term Test-Driven Design over Test-Driven Development.

Test After

We will look at a simple example to illustrate the difference between test first and test after approaches. Let's say we we are building a billing system for a clinic. One of the functionalities is to collect payment from a patient for the services tendered. We will use Test After approach. As an exercise, I created a and a getPayment() method. It came to me naturally that in order to calculate amount owed by a patient, I would need a list of services that are provided to the patient. So, I added a parameter to my getPayment method. The implementation looks like the following:
public class Patient {

// ...

public double getPayment(List servicesTendered) {

double payment;
if (servicesTendered.size() > 0) {
payment = calculateAmountOwed(servicesTendered);
} else {
payment = 0d;

return payment;

// ...

The test I produced based on the above implementation is as follow:
public void testGetPayment() {
Patient patient = new Patient();

assertEquals(patient.getPayment(new ArrayList()), 0d);

We can easily implement similar test to test for non-zero service list. The above test is good enough for our discussion. So far, everything looks good. I am happy with this implementation.

Test-Driven Design (Test First)

In Test After, I implement getPayment method by thinking of what do I need in order to implement the method. In test first, I have to change my mind set. I need to think of how to create some test code to test the getPayment method. In other words, I need to think of how to use my code in the test. Below is the test code I produced by using test first approach:

public void testGetPayment() {
Patient patient = new Patient();

patient.addService(new Service(LAB_WORK));

assertEquals(patient.getPayment(), 15d);


The above test method is different from the previous one. The difference is I don't pass in a list anymore. When I write test first, I am thinking from a patient perspective. When a service is tendered, it should be added to the patient. It is just like an on-line shopping cart. A customer can add any items in store to his/her basket. Similarly, a patient should be able to add services tendered to him/her. Below is the new getPayment implementation.
public double getPayment() {

double payment;
if (servicesTendered.size() > 0) {
payment = calculateAmountOwed();
} else {
payment = 0d;

return payment;

The calculateAmountOwed method does not need a list of services anymore. The service list is available in the Patient class.

Since we design and write test at the same time, no time is wasted. The test we wrote serves two purposes:
  1. Artifact. The test tells other developers how to use our code.
  2. Safety net. The test allows other developers to modify our code confidently.
Another benefit of writing test first is we can change our code easily since no actual code is written yet. If we do test after, we tend to avoid making changes to our implementation even if our design is wrong. We will try to tweak our test to comply with our implementation. As a result, our test may still pass even though our implementation does not work correctly.

Further readings:

Neal Ford wrote a nice two parts article on Test-Driven Design with more advance examples:
  1. Test-driven design, Part 1
  2. Test-driven design, Part 2

Sunday, October 11, 2009

Code better than yesterday

Code maintenance is a big part of a developer's job. After we write our first method and then go back to fix it, it is a maintenance job 1. This is true for developing a new application from scratch or making enhancement to an existing application. But, developers often don't see it that way. When we inherit a poor written application, we lose a lot of freedom and creativity in creating our own solution.

I happen to inherit a poorly written application from time to time. When I inherit such application, I am not very motivated to work on the application. Everyday is a torture for me to just look at the legacy code. The code is poorly written, application architecture is accidental, no test cases or some of the test cases don't have assert statements. I complete the tasks I am asked to do by putting down the solution that first comes to my mind without refining it so that I can finish the project as soon as possible and move on to the next project. But, what if the next project is worse than the project I had before? So, the evil cycle continues.

I didn't resolve to hacking my solution overnight. At the beginning of the project, I was determined to make the project better by recommending some of the pragmatic approaches to be adopted in the project. I had a long discussion with the team and everyone thought those were good ideas. But, everyone had higher priority on their plates and none of the good ideas were realized. I tried to put in some tests, refactored some of the code that I was working on so that it is testable. But, no matter what I did, it didn't seem to have an impact to the overall application. So, I gave up and went down to the code hacking path. I fell into the trap of Broken Window Theory.

The truth is, I lost focus. I care too much about the end result. I should focus on completing today's tasks to the best I can by refactoring the legacy code into testable code and refactoring long method into smaller methods using composed method pattern. I should fix one broken window at a time and not attempting to fix all the broken windows overnight. If I have done something to make today's code better than yesterday, I have achieved something and I should be happy about it1. I may not see a big difference as a whole but incremental improvement is the first step to improving the whole application. If I stay on this path, the developers around me may see the benefit of the good practices I am adopting and start following.

1. The Passionate Programmer

Sunday, August 16, 2009

Prototype Programming

I have been playing with dynamic languages such as Ruby and Groovy. I like what I see so far. Also, I have been relearning JavaScript as a true dynamic language. I came across this concept called prototypical inheritance in JavaScript and it is fascinating. The idea of prototypical inheritance is to create a new object from an old object and then add "stuff" to it. Here is a simple JavaScript example:

// convenient method extracted from Douglas Crockford's
// website -
if (typeof Object.create !== 'function') {
Object.create = function (o) {
function F() {}
F.prototype = o;
return new F();

var animal = {
name : "",
get_name: function () {

var cat = Object.create(animal); = "Mr. Black";
cat.says = "meow";

document.writeln( + " " + cat.says);

// Mr. Black meow

Instead of doing classical inheritance in static language such as Java, we simply add "says" method to the newly created cat object.

Interesting enough, there is way to achieve the same thing in Ruby:

animal =



cat = animal.clone = "Mr. Black"

def cat.says

puts + " " + cat.says # Mr. Black meow

Now, the "says" method is added to the cat object.

"class" does not exist in both JavaScript and Ruby. Everything is Object in JavaScript and Ruby.

It is possible to achieve the same thing in Java using AOP through Spring or AspectJ. But, we have to learn Spring or AspectJ first before integrating either of them into our application. Productive language like Ruby has this capability built in and developer can just use it without incurring huge upfront cost. I hope this is the first step to convincing some of my colleagues why using a productive language like Ruby or Groovy is important.

The usage of prototypical inheritance is unclear at the moment. But, reusing a chunk of code across objects is important. Usually, this is done through inheritance even though there is no "is-a" relationship. Deep inheritance can cause unnecessary complexity in our application. In Ruby, this problem can be solved using Module and Mixin.