Test Driven Development

The basic philosophy in this approach is to develop a series of tests against which software is written.

It's an incremental approach meaning, write a test, write some production code against that test to pass the test. If the previous test passes, write another test, write more production code against the new test to pass the new test and ensure that the preceding tests do not fail. With the addition of each new test, you should not change the preceding tests to match the new production code, instead the new production code should not break the preceding tests.

The idea is commonly termed RED-GREEN-REFACTOR

RED - write a test, run the test, it will fall, write just enough production code to pass the test (GREEN)

GREEN - push your code to a repo (only push code that passes it's tests to a repo)

REFACTOR - clean up the code, make sure the tests still pass

Why is this an important move away from the traditional approach of writing code first then writing tests after? With this approach, the developer writes tests with the minds eye of the internal functionally being tested (white box testing). If we write the tests before the production code, the tests help to drive the interface of the Class Under Test (CUT) because each test method comprises of three parts

• An Arrange

• An Action

• An Assertion

The three A's.

Arrange - you set up your

• Input values

• Expected output values

• A variable to hold the result

• An instance of the CUT

Act - you invoke the method being tested on the CUT

• This helps you define the interface of the method on the CUT

Assert - Test the result from the Act method against the expected output values

• assert actual_result == expected_result