CSC/ECE 517 Fall 2014/ch1b 28 cg

What is Test-Driven Development?

Test driven development(TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.

Development cycle

A typical TDD development cycle could be simply described as followed

• Write an automated test before write code. While writing the automated tests, you must take into account all possible inputs, errors, and outputs. This way, your mind is not clouded by any code that's already been written.
• Run automated test, the test should fail—indicating that the code is not yet ready.
• Program to pass the test. Since there's already an automated test, as long as the code fails it, it means that it's still not ready. The code can be fixed until it passes all assertions.
• Begin cleaning up codes and remove redundancy via refactoring. As long as the code still passes the test, it means that it still works. You no longer have to worry about changes that introduce new bugs.
• Repeat the whole process.

"Test-driven development". Via Wikimedia Commons

What is Behavior-Driven Development?

Definition

BDD(Behavior Driven Development) is a synthesis and refinement of practices stemming from TDD(Test Driven Development) and ATDD(Acceptance Test Driven Development). Behavior driven development combines the ideas from domain-driven design and object-oriented analysis design, providing the collaboration between business interests and technical insights with shared tools and shared process to collaborate on software development. During the "Agile specifications, BDD and Testing eXchange" in November 2009 in London, Dan North[6] gave the following description of BDD:

   BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions
   with well-defined outputs, resulting in the delivery of working, tested software that matters.

History

However, in 2007, a group of Agile practitioners, including Dan North and Dave Astels, started rocking the boat, with presentations and tool development work. They believed that it is possible to write high quality, well-tested, reliable, and maintainable code, and miss the point altogether. As software developers, the main goals is to help customers to solve problems. Behavior driven was a response to the lack of any specification within TDD of:

• What to test and what not to test
• How much to test in one go
• What to call the test
• How to understand why a test fails

They started from the common use of story template that starts like this:

• As a [role],
• I want a [feature],
• So that [I gain some benefit].

Dan North and his collaborator created a template to capture a story’s acceptance criteria and described it as scenarios. The scenarios break the story into constituent segments and can be automated for analysis. It took the following form:

• Given some initial context (the givens),
• 
When an event occurs,

• then ensure some outcomes.

Based on this, North and others developed the Behavior driven framework over a period of years, finally framing it as a communication and collaboration framework for both technical and nontechnical participants.

Dan North created the first ever BDD framework, JBehave,[1] followed by a story-level BDD framework for Ruby called RBehave[7] which was later integrated into the RSpec project.[8] He also worked with David Chelimsky, Aslak Hellesøy and others to develop RSpec and also to write "The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends". The first story-based framework in RSpec was later replaced by Cucumber mainly developed by Aslak Hellesøy.

In 2008, Chris Matts, who was involved in the first discussions around BDD, came up with the idea of Feature Injection, allowing BDD to cover the analysis space and provide a full treatment of the software lifecycle from vision through to code and release.