This below is an excerpt from Agile Testing Foundations: An ISTQB Foundation Level Agile Tester Guide written by Rex Black, Marie Walsh, Gerry Coleman, Bertrand Cornanguer, Istvan Forgacs, Kari Kakkonen, and Jan Sabak, published July 2017. The authors are all members of the ISTQB Working Group that wrote the ISTQB Agile Tester Foundation syllabus.
Kari Kakkonen wrote this selection & this article was originally published at RBCS. Copyright BCS (British Computer Society).
Test-Driven Development, Acceptance Test-Driven Development, and Behaviour-Driven Development by Kari Kakkonen
The traditional way of developing code is to write the code first, and then test it. Some of the major challenges of this approach are that testing is generally conducted late in the process and it is difficult to achieve adequate test coverage. Test-first practices can help solve these challenges. In this environment, tests are designed first, in a collaboration between business stakeholders, testers, and developers. Their knowledge of what will be tested helps developers write code that fulfils the tests. A test-first approach allows the team to focus on and clarify the expressed needs through a discussion of how to test the resulting code. Developers can use these tests to guide their development. Developers, testers, and business stakeholders can use these tests to verify the code once it is developed.[1]
A number of test-first practices have been created for Agile projects, as mentioned in section 2.1 of this book. They tend to be called X Driven Development, where X stands for the driving force for the development. In Test Driven Development (TDD), the driving force is testing. In Acceptance Test-Driven Development (ATDD), it is the acceptance tests that will verify the implemented user story. In Behaviour-Driven Development (BDD), it is the behaviour of the software that the user will experience. Common to all these approaches is that the tests are written before the code is developed, i.e., they are test-first approaches. The approaches are usually better known by their acronyms. This subsection describes these test-first approaches and information on how to apply them is contained in section 3.3.
Test-Driven Development was the first of these approaches to appear. It was introduced as one of the practices within Extreme Programming (XP) back in 1990s.[2] It has been practiced for two decades and has been adopted by many software developers, in Agile and traditional projects. However, it is also a good example of an Agile practice that is not used in all projects. One limitation with TDD is that if the developer misunderstands what the software is to do, the unit tests will also include the same misunderstandings, giving passing results even though the software is not working properly. There is some controversy over whether TDD delivers the benefits it promises. Some, such as Jim Coplien, even suggest that unit testing is mostly waste.[3]
TDD is mostly for unit testing by developers. Agile teams soon came up with the question: What if we could have a way to get the benefits of test-first development for acceptance tests and higher level testing in general? And thus Acceptance Test-Driven Development was born. (There are also other names for similar higher-level test-first methods; for example, Specification by Example (SBE) from Gojko Adzic.).[4] Later, Dan North wanted to emphasize the behaviours from a business perspective, leading him to give his technique the name Behaviour-Driven Development.[5] ATDD and BDD are in practice very similar concepts.
Let's look at these three test-first techniques, TDD, ATDD, and BDD, more closely in the following subsections.
[1] This concept is not unique or new to Agile development. Boris Beizer, in his book Software Testing Techniques, talks about the value of a test-first approach to software development.
[2] You can find the initial description in Kent Beck's Test-driven Development: By Example.
[3] You can find Coplien's article, "Why Most Unit Testing is Waste," at http://rbcs-us.com/resources/articles/why-most-unit-testing-is-waste/
[4] One widely-read source on the topic is Adzic's Bridging the communication gap: Specification by Example and Agile Acceptance Testing.
[5] A good discussion on this topic is Chelimsky's The RSpec Book: Behavior Driven Development with Rspec, Cucumber, and Friends.
To see the remaining contents of the article in its entirety on the Knowit site click here or to read it at the original RBCS location click here!
More on Knowit:
Similar content can also be experienced in ISTQB Agile Tester courses by Kari Kakkonen and other Knowit trainers. Page content is in Finnish, but courses in English are also available,
We also offer testing and quality assurance services and are constatly looking for new people for our teams!