TDD Heuristics: Act Dumb in Implementation

When we have written a failing test, we try to make it work in the simplest possible way - do the simplest thing that could possibly work. We prefer baby steps, so at each step we understand precisely what we are doing, even if we have not solved the whole problem yet. Cheating and faking are allowed.

We act dumb in implementation. With ‘dumb’ we mean keeping it very simple and straightforward. We do the bare minimum to make the test green, not the tiniest bit more. We don’t write complicated code or conditionals to make the test pass. If we would need complicated code, it’s simpler and better to use a proper (but still simple) implementation instead.

Example

Let’s look at another example from the drinks vending machine we mentioned earlier. We write a test for the vending machine delivers a drink when you have paid the exact price.

1
2
3
4
5
6
@Test
public void deliversWhenPaidExactPrice() {
  ...
  machine.pay(1);
  assertThat(machine.deliver(Choice.Cola), is(Optional.of(Can.Coke)));
}

To make this test pass, we need to perform some comparison. Maybe you’re thinking of something like checking if the amount paid is less than or equal to the price of the drink, but we prefer to start with just checking equality.

1
2
3
4
5
6
7
8
class VendingMachine {
  public Optional<Can> deliver(Choice choice) {
    ...
    if (amountPaid == this.price) {
      ...
    }
  }
}

The == is sufficient to make our test pass, even though we know that we will need a ‘>=’ eventually. We don’t have a test for this case yet, so we go for the simpler equality. We know that we have to write a new test, for instance delivers drink when paid more than the price. This helps us to take baby steps.

Effects

Even though we often have the ‘proper’ solution already in our heads, we apply this guideline to take baby steps towards our goals. We frequently end up with a simpler, more elegant solution than we initially imagined. As developers we are good at thinking up complicated solutions and handling these, this guideline helps us to arrive at simpler code. Which also gives us less to handle later on.

By taking small steps, we force ourselves to add tests for edge cases. We know that == is not good enough, so we write an extra test that will fail initially. It is the path of least resistance towards covering both happy paths and edge scenarios.

We are notoriously bad at things like getting our comparators right and getting -1/+1 boundaries correct. The Act Dumb in Implementation guideline helps us getting this right from the start. It has saved us a lot of issues.

Act Dumb in Implementation works well in a ‘ping-pong’ pair programming setting, where one person writes the test, and the other tries to get away with writing the bare minimum amount code needed to make the test pass. This is great fun to do, and really sharpens our sense for what is minimal.

Further reading

The Do The Simplest Thing That Could Possibly Work rule originates from eXtreme Programming. This rule focuses on radical simplicity in your code. By keeping it in mind, you intend to refrain from thinking ahead of all kinds of possible scenarios and creating generic solutions.

Keeping the working code as simple as possible, does not mean we will code ourselves into a corner. On the contrary, we keep more options open, because there is less code getting in the way when we need to change it later on.

Keeping things simple has all kinds of second order effects, like Kent Beck states in this little gem found on the Do The Simplest Thing That Could Possibly Work page on the C2 wiki:

There are second order effects to asking yourself “What is the simplest thing that could possibly work?” – KentBeck

• You get done sooner
• Your work is easier to communicate
• Duplication is obvious, so the needs and means for refactoring are clearer
• Tests are easier to write
• The code is easier to performance tune Or, at least, there will be more scope for tuning performance
• You feel less stress, which enhances all of the above

Read more about the Simplest Thing That Could Possibly Work.

This is a post in our series on Test Driven Development.