Testing is rarely a recipe.

Testing is rarely a recipe.

Test Driven Development (TDD) is an approach to development in which you write a test that proves the piece of work you are working on, and then write the code required to pass the test. There are a number of different versions of the basic TDD concepts driven by different development philosophies.  The most common are:

  • Test Driven Development (TDD) – The classic extension of test-first development that incorporates code and design refactoring.  A developer using TDD will develop a test(s) for the unit of work he or she is working on first. Then run the test(s) to validate that it fails.  Once the test fails he or she writes only the code needed to satisfy the unit of work.  The code and test are repeated until the tests are passed.  Finally, design refactoring is performed based on the implementation of the code. The tests that are written in a TDD environment tend to be focused on unit and functional testing. TDD was originally linked to Extreme Programming, where the practice of pairing (two developers working together on one unit of work) helped to ensure that the tests were not tailored to pass based on an individual developers point of view. TDD proves that the work was done correctly.
  • Acceptance Test Driven Development (ATDD) – ATDD begins by generating a set acceptance test cases based on the team’s shared understanding of the units of work the team is being asked to deliver.  The goal of ATDD is to ensure everyone on the team has the same perception about what is being built. ATDD ensures that the right things are getting built.  Acceptance tests cases nearly always provide additional depth for a user story or the requirements which further supports generating a shared vision among the team
  • Behavior Driven Development (BDD) – BDD leverages facets of both TDD and ATDD.  From TDD  we take the unit/functional test focus  and from ATDD we bring int the acceptance test focus.  Test formats tend to be in an object oriented class format that specifies the desired behavior of the unit of work.  Sample of BDD test formats are: Given <initial context>, when <event>, then <outcome>. I have seen and used variants that include formats such as [given, when, then, and] or [given, but, then] and other variations. In BDD, tests are written in a precise format that supports automation if the test (an example of writing tests in a specific manner is Cucumber), while at the same time are representing real behaviors and being human readable.

Test Driven Development and its cousins, ATDD and BDD, are not only development approaches but also communication tools.  TDD tends to focus communication within the core team. ATDD, while still focused on the core team, can also be used to incorporate stakeholder participation by including stakeholders in generating tests.   BDD can be used to bridge the communication gap between stakeholders, developers and testers by making tests represent explicit behaviors that all parties can read and understand. Writing tests first helps everyone understand what will be developed and in proving that what was developed meets that understanding.

Advertisements