A Look Inside Test-Driven Development

function {define what it is}

Test-driven development (TDD) requires that before any application code is written, a corresponding test code is written. The test code verifies that when the application code runs, the outcome matches the objective defined in the project requirements.

Think of a school teacher who creates a lesson plan by first outlining the learning objective. By stating the objective at the start, the instructor will have a standard by which to measure the student’s progress. If a student fails the test, the teacher will revise the lesson plan and reassess the student’s performance. This process may continue until the student is proficient.

function {show how it works}

Test-driven development may be applied to a wide range of software development scenarios. Take a user registration module, for instance. The module might expect to receive a username and password from a user. A test for this module would be expected to fail when:

• no username is given
• no password is given
• the password is too short
• the password does not conform to some composition requirements (numbers, letters, symbols, capitalization, etc)
• the user does not exist

In this case, we would write a test to check that the first condition was met: was a username provided? If the test code is run at this point, it will fail because the corresponding app code has not been written.

• After the app code that models a login submission is written, it is tested with a username provided.
• The test should pass. If it fails, the reason is determined and the error corrected.
• The test is run again with the updated code. This process continues until the test is passed.
• These steps are repeated for each subsequent condition.
• Code is refactored to achieve the simplest, effective solution, which is verified by retesting

When all the tests have passed, we know that our module complies with the given requirements.

function {explain why it matters}

Ultimately, TDD helps improve code quality and reduce overall development time because it requires a complete architecture. After all, you can’t write a test if you don’t know what your code is expected to do. TDD also reduces the likelihood that some essential functionality will be overlooked and have to be cobbled in at the end, which entails the risk of breaking existing code.

Test-driven development also imposes discipline on the coding process itself. As the test suite and application code are developed in tandem, coding doesn’t get ahead of testing. If code is developed in the absence of testing, errors written into the code early may cascade across the architecture, greatly increasing the difficulty of finding or resolving them. As code evolves, with the addition of features or through routine maintenance, having unit tests in place makes subsequent regression testing faster and easier.

function {wrap it up}

Over the last 20 years, TDD has matured as a subdiscipline within software development for the rigor it brings to the development process. Although it requires additional time in the early phases of development, it expedites subsequent testing through the elimination of errors before code is integrated. At Paradigm, we’re proud to make TDD our standard procedure for software development, because it fosters the efficiency and reliability our clients expect from us.