Test-driven development

Test-driven development2017-10-12T22:05:27+00:00

TDD workflow

Context

Summary

Provide a summary of this practice.

Test-Driven Development (TDD) is a test-first approach to development.

For background to TDD, see here.

Purpose

What is the overall goal or intention of this practice?

Test-Driven Development is designed to implement stories with the minimum of high-quality code.

SLA

What are the schedule, cost, quality, frequency, performance or other expectations for completing this practice?

N/a.

Exit conditions

What must have happened or been delivered for this practice to be considered complete?

  • The story has been fully implemented.
  • The user is fully satisfied.
  • The working software consists of high-quality code.

Entry conditions

What pre-conditions must be met before this practice is used?

  • User/developer pair has been established.
  • Backlog stories are mature and prioritised.

Outline process

This view shows a simplified version of this process. For full details, explanation and advice, click on the ‘Detailed process’ tab. For background such as entry and exit conditions, click on the ‘Context’ tab.

#StepInstructions
1Select next story.
  1. Identify next story.
  2. Set up environment for development.
2Create test.
  1. User describes a test for a component of the story.
  2. Developer encodes the test.
3Run test.
  1. Developer runs the test.
4Pass?
  1. Developer & user check that code passes all tests.
5Make a change.
  1. Create the desired (change to) function.
6Finalise code.
  1. Refactor code.
  2. Review code against Definition of Done.
7Repeat test.
  1. Re-apply tests.
8Pass?
  1. Developer & user check that code still passes all tests.
9Story done?
  1. User decides whether the story has been implemented satisfactorily.

Detailed process

#StepByOutputInstructionsNotes
1Select next story.Developer.

User.

Development environment set up for story.
  1. Identify next story.
  2. Set up environment for development.
  • Normally the ‘next story’ is the next item in the prioritised iteration backlog appropriate for this user/developer pair.
  • Check previous test fixtures have been removed.
  • Some refactoring may be required to make existing code suitable for the new story.
    • If so, re-run all existing tests before making any further changes.
2Create test.Developer.

User.

Agreed test.
  1. User describes a test for a component of the story.
  2. Developer encodes the test.
  • The capability created in any single code/test loop is typically only a small part of the story being implemented.
  • See Good Practice in TDD.
 3Run test.Developer.Test results.
  1. Developer runs the test.
  • Before writing any code, check that the test fails for the expected reasons.
  • Final tests should run full test suite.
  • This will also check all other code & tests are not broken.
4Pass?Developer.

User.

Pass/fail decision.
  1. Developer & user check that code passes all tests.
  • On first pass, check that the code fails for the expected reasons.
  • Code is rejected if:
  • Any tests fail.
  • Tests pass but the user is still dissatisfied.
  • Every bug should lead to a new test.
  • Every aspect of user dissatisfaction should lead to a new test.
5Make a change.Updated code.
  1. Create the desired (change to) function.
  • Write only the code needed to pass the test.
  • All changes must be justified by a test.
  • Avoid ‘nice-to-have’ or ‘what-if’ code.
  • Code very small increments between tests.
  • It is often quicker to undo or revert than debug.
  • Code need not be ideally elegant – code will be optimised later.
6Finalise code.Developer.Optimised code.
  1. Refactor code.
  2. Review code against Definition of Done.
  • It is likely that only limited parts of the full Definition of Done will apply to any single story.
7Repeat test.Developer.Test results.
  1. Re-apply tests.
  • Is the code functionally identical to the previously passed code?
8Pass?Developer.

User.

Pass/fail decision.
  1. Developer & user check that code still passes all tests.
9Story done?User.
  1. User decides whether the story has been implemented satisfactorily.
  • Only the user can decide whether the story should be accepted.

Issues & risks

What are the key concerns in making a success of this practice?

  • TDD needs to be applied by all teams working on a given codebase.
  • Understand the limits of TDD.
  • Agree explicit TDD standards & procedures.
  • Aim for at least 90% code coverage in the working software.
  • Create an effective TDD environment.
  • Continuous integration, fast compilers, etc.
  • For multi-day stories, refactor daily.
    • This will simplify the next day’s work.
    • And make tomorrow’s refactoring much easier.
  • Treat test code as seriously as application code.
  • Keep the development process as simple as possible. For example:
    • Limit edits to 1-10 before testing.
    • Avoid interfacing with complex or dynamic objects until the code is nearly complete.
    • Etc.
  • It takes a long time to learn the test-first discipline.
    • It is helpful if the Iteration Lead tracks progress.
  • Testing alone is not enough.
    • Even if all tests are passed, the user may still be dissatisfied.
  • TDD is not an excuse to abandon good engineering practice.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?