Loading...
 
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle

Test Driven Development (TDD)

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.

Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.

Programmers also apply the concept to improving and debugging legacy code developed with older techniques.1

Unit Testing

In computer programming, Unit Testing is a software testing method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures are tested to determine if they are fit for use.2

Unit Tests are primarily written as a good practice to help developers identify and fix bugs, to refactor code, and to serve as documentation for a unit of software under test. To achieve these benefits, unit tests ideally should cover all the possible paths in a program. One unit test usually covers one specific path in one function or method. However, a test method is not necessary an encapsulated, independent entity. Often there are implicit dependencies between test methods, hidden in the implementation scenario of a test. --Adrian Kuhn et. al. 3

Rules

  • Write new code only if an automated test has failed
  • Eliminate duplication

Behavior

  • We must design organically, with running code providing feedback between decisions
  • We must write out own tests, because we can;t wait 20 times per day for someone else to write a test
  • Out development environment must provide rapid response to small changes
  • Out design must consist of many highly cohesive, loosely coupled component, just to make testing easy

Programming Tasks

  1. Red — Write a little test that doesn't work, and perhaps doesn't event complie at first
  2. Green — Make the test work quickly, committing whatever sins neccessary in the process
  3. Refactor — Eliminate all of the duplication creating in merely getting the test to work

TDD Cycle

  1. Write a test. Think about how you would like the operation in your mind to appear in your code. You are writting a story. Invent the interface you wish you had. Include all of the elements in the story that you imagine will be neccessary to calculate the right answer.
  2. Make it run. Quickly getting that bar to go to green dominates everything else. If a clean, simple solution is obvious, then type it in. If the clean, simple solution is obvious but it will take you a minute, then make a note of it and get back to the main problem, which is getting the bar grden in seconds. This shift in assthetics is hard for some experienced software engineers. They only know how to follow the rules of good engineering. Quick green excuses all sins. But only for a moment.
  3. Make it right. Now that the system is behaving, put the sinful ways of the recent past behind you. Step back onto the straight and narrow path of software righteousness. Remove the duplication that you introduced, and get to green quickly.

Overview

Test-driven development (TDD) (Beck 2003; Astels 2003), is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring. What is the primary goal of TDD? One view is the goal of TDD is specification and not validation (Martin, Newkirk, and Kess 2003). In other words, it’s one way to think through your requirements or design before your write your functional code (implying that TDD is both an important agile requirements and agile design technique). Another view is that TDD is a programming technique. As Ron Jeffries likes to say, the goal of TDD is to write clean code that works. I think that there is merit in both arguments, although I lean towards the specification view, but I leave it for you to decide.4

Kent Beck, who popularized TDD in eXtreme Programming (XP) (Beck 2000), defines two simple rules for TDD (Beck 2003). First, you should write new business code only when an automated test has failed. Second, you should eliminate any duplication that you find. Beck explains how these two simple rules generate complex individual and group behavior:5

  • You develop organically, with the running code providing feedback between decisions.
  • You write your own tests because you can't wait 20 times per day for someone else to write them for you.
  • Your development environment must provide rapid response to small changes (e.g you need a fast compiler and regression test suite).
  • Your designs must consist of highly cohesive, loosely coupled components (e.g. your design is highly normalized) to make testing easier (this also makes evolution and maintenance of your system easier too).

For developers, the implication is that they need to learn how to write effective unit tests. Beck’s experience is that good unit tests:6

  • Run fast (they have short setups, run times, and break downs).
  • Run in isolation (you should be able to reorder them).
  • Use data that makes them easy to read and to understand.
  • Use real data (e.g. copies of production data) when they need to.
  • Represent one step towards your overall goal.

Articles


1 Test-driven development. (2013, October 9). In Wikipedia, The Free Encyclopedia. Retrieved 03:04, October 13, 2013, from http://en.wikipedia.org/w/index.php?title=Test-driven_development&oldid=576503904
2 Unit testing. (2014, May 22). In Wikipedia, The Free Encyclopedia. Retrieved 00:49, June 13, 2014, from http://en.wikipedia.org/w/index.php?title=Unit_testing&oldid=609698259

Last edited by MichaelAlber .
Page last modified on Thursday October 14, 2021 17:14:19 PDT.

Books