Starting the Test Driven Development Habit - Ping Pong

When solving a problem with code, the solution will always feels faster to jump in and write the code out the solution instead of writing out the test first then the code.

It’s almost ironic but to be good at test driven development, one has to basically know:

• the programming language they are solving the problem in
• the testing framework in place
• how to construct a test for what they want to test
• write the question to the solution they are implementing
• know the question well enough to construct both the test and the solution.

This is a tall order and it was not easy for me to learn.

After all the pain, test driven development is worth doing. I will share my thoughts on this and why

If you don’t know any of the above, talk to me. That’s why I am here, to help you on your way to being: “test first”.

If you want to try alone, which I understand - experience is a great teacher, here’s my first two suggestions:

• make the smallest failing test
• test/code ping-ping with yourself

Smallest Failing Test

Write the smallest failing test you can, even if it’s something like:

expect(true).to equal(false)

You need to know your test framework is functional and what errors will look like.

This will also make you figure out a lot about your system - so it’s an essential first test to have.

Test/Code Ping-Pong

Building on the smallest failing test, write the smallest failing test with a function you can write.

expect(function(true)).to equal(true)

Then, run the test suite, there will be lots of errors - that’s expected. Just solve those errors one by one.

• include the file
• write out the function
• have the function return a value

The goal is not to “get it all done in one step”, it’s to take baby steps each time. Seeing how error messages change as you progress towards a solution until finally, there’s just a passing test.

If you see the same error after successive changes, then I have to ask:

Are your changes helping you move toward your goal if the error message is the same?

Every change should change something. If not, that change is not needed.

In the above the solution should be so simple as:

def function(variable)
  return true
end

Once the test passes with the code, add another test:

expect(function(false)).to equal(false)

Go back and write the code to get that test passing and all previous tests.

The challenge now is to get all tests passing with the minimal code changes possible.

An article that explains this in another way: Test Driven Design - JJ Seymour