Abstract

Keywords:

Test Driven Development, Behaviour Driven Development, Acceptance Test Driven Development

Test Driven Development (TDD)

TDD³ is a software development technique. In this development technique, we create test cases¹ first, and then we write the code underlying those test cases. Three important points to remember when talking about TDD are:

• It means writing tests that fail because the functionality does not exits.
• It is a development practice.
• Developers write the tests.
• Main focus: Unit testing

TDD process is simple and straightforward. We start by writing a test. We execute the test and watch it fail. We modify the code and re-execute the code. If test passes, we can either stop or add new test. If test fails, we modify the code until, the test passes.

TDD methodology follows a simple 6 step process:

1. Write a test case: Based on the requirements, write an automated test case.
2. Run all the test cases: Run these automated test cases on the currently developed code.
3. Develop the code for that test cases: If the test case fails, then, write the code to make that test-case work as expected.
4. Run test cases again: Run the test cases again and check if all the test cases developed so far are implemented.
5. Refactor your code: This is an optional step. However, it’s important to refactor your code to make it more readable and reusable.
6. Repeat the steps 1- 5 for new test cases: Repeat the cycle for the other test cases until all the test cases are implemented.

Don’t be confused TDD or BDD with Domain Driven Design (DDD). Domain-driven design (DDD) is the concept that the structure and language of software code (class names, class methods, class variables) should match the business domain.

Behaviour Driven Development (BDD)

BDD is regarded as an extension of TDD where instead of writing test cases, we start writing executable specifications. Later, we write the code which is required to abide by these specifications. Four essential points you need to remember about BDD are as follows:

• It means writing executable specifications that fail because feature does not exits.
• It is team methodology.
• Executable specifications are written by developers, users or testers.
• Main focus: Understanding requirements

BDD process

The process involved in BDD methodology consists of 6 steps and is similar to that of TDD.

1. Write the behavior of the application: The behavior of an application is written in simple English like language by the product owner or the business analysts or QAs.

2. Write the automated scripts: This simple English like language is then converted into programming tests.

3. Implement the functional code: The functional code underlying the behavior is then implemented.

4. Check if the behavior is successful: Run the behavior and see if it is successful. If successful, move to the next behavior otherwise fix the errors in the functional code to achieve the application behavior.

5. Refactor or organize code: Refactor or organize your code to make it more readable and re-usable.

6. Repeat the steps 1-5 for new behavior: Repeat the steps to implement more behaviors in your application.

Example of executable specifications

Context: Login page
Event: Enter username and password and hit Login button.
Outcome: I am logged into the user dashboard page.

ATDD (Acceptance Test Driven Development)

• It is similar to BDD, however BDD focuses mainly on behaviour of a feature where as ATDD focuses on capturing the accurate requirement.
• It is a team methodology.
• Developers, customers, WAs
• Main focus: Writing acceptance tests

TLDR

If you landed on this blog without understanding software design and modelling tools, you might want to stop it here and read this post first.

Which is the right fit for my company?

There is no right answer. Some developers might argue TDD is better than BDD, however, it depends on the person, the project, team lead and methodology. TDD gives you high code coverage ² whereas BDD is better in finding the workflow bugs.

Glossary Alert

Test cases: In software engineering, a test case is a specification of the inputs, execution conditions, testing procedure, and expected results that define a single test to be executed to achieve a particular software testing objective, such as to exercise a particular program path or to verify compliance with a specific requirement. ↩

Code coverage: In computer science, test coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs. ↩

TDD: Beck, Kent. Test-driven development: by example. Addison-Wesley Professional, 2003.↩