You are currently browsing the category archive for the ‘programming’ category.

[user]
    email = joseph.vano@gmail.com
    name = Joey Vano
[core]
    autocrlf = false
[diff]
    external = c:/users/jvano.fcs/difftool.sh

[merge]
    keepBackup = false;
    tool = p4merge

[mergetool "p4merge"]
    cmd = "p4merge.exe" "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
    keepTemporaries = false
    trustExitCode = false
    keepBackup = false
[color]
    ui = auto

Advertisements

Test Driven Development By Example outlines a few strategies for getting your tests to green.

  1. Fake It
    1. This is the quickest way to get it green.  Simply supply a constant value at first to get it passing.  Once it turns green, replace it with  a variable and continue until you have the real code that is needed there.
  2. Use Obvious Implementation
    1. If you are confident and you know the correct implementation, simply write it.  The test will validate that you are right.
  3. Triangulation
    1. Write two or more examples that generalize code.  This is the most conservative approach.

These strategies can be used interchangeably when doing TDD.  If you put it on a scale of when to use which strategy, Obvious Implementation is on the far left, being the most free and not needing to check with dummy values.  The far gaspedalright is Triangulation.  It requires multiple examples to validate the code.   This does create some duplication, but enables you to make small steps in the code.

When coding, you can use these strategies like a gas pedal.  If you know the implementation, step on the pedal and use Obvious Implementation.  But if you hit a red light, time to switch gears and maybe go to Fake It or Triangulation to get back green.

From Kent Beck’s book Test-Driven Development By Example I’ve learned a few quite simple rules.

The two essential rules:

  1. Write new code only if there is a failing automated test
  2. Eliminate Duplication

The more systematic way of doing TDD:

  1. Add a test
  2. Run all tests and fail
  3. Make a little change
  4. Run tests and pass
  5. Refactor to remove duplication

This method can be broken down even further to:

  1. Red – write a failing test
  2. Green – make it pass
  3. Refactor – remove duplication

This is more widely known as the TDD Mantra.

The ability to work in small steps thus strengthens our confidence in the software we build.

In programming, if you fear the unknown, write some tests!