Test-Driven Development (TDD)

In the last step, we learned about unit tests and characteristics of proven unit tests. In this step, we cover test-driven development (TDD).

Test-driven development, or TDD, is a development methodology that lets the tests drive the production of code. This ensures that the tests reflect what the code ought to do and that all methods in the public class interface are tested

The essential points are:

• Tests, based on specifications, are written before any code.
• The aim is to pass the tests; anything else is superfluous.
• Lines of code are written only if they help a class pass a test.
• After all the tests are passed, the code is complete.

The steps are:

1. Quickly add a test.
2. Run all tests and see the new one fail.
3. Make a little change.
4. Run all tests and see them succeed.
5. Refactor to remove duplication.

Other helpful unit-testing processes

• Stubs. Stubs provide panned answers to calls made during the tests, usually not responding at all to anything outside what’s programmed in for the test.
• Mocks. These are objects pre-programmed with expectations that form a specification of the calls that they are expected to receive.
• Fakes. These are objects that actually have working implementations but usually take some shortcut that makes them unsuitable for production (in-memory database, for example).

Remember to engage in peer discussions or share experiences in the comment section below. In the following step, we will explore integration tests.