What is Test-Driven development (TDD)?

This is a development approach where software requirements are converted into unit test cases before the development of the software. Since it pre-defines the test cases before development it is thus referred to as test-driven design.

Unlike traditionally in software development, where the code is written and then test cases are created and tested, in TDD test cases are first developed before the code is written. The code is then continually tested against the test cases throughout the development process until a complete unit is achieved.

It encourages short development cycles because the test cases are created in the smallest unit of functionality so that each unit is tested and has to pass before other units are added to the design.

There are three rules in TDD that are standard practice namely:

• The failing test must be written before any production code is written.
• More of a test should not be written than is sufficient to fail or fail to compile
• More production code than is sufficient to make the currently failing test pass should not be written

How TDD works

Here is how TDD works:

• Write a test
• Run the test or tests and watch them fail
• Write the code
• Test the code
• Refactor
• Repeat the steps

Benefits of TDD

Some of the benefits of Test-driven development include:

• Faster development

With the tests being specified at the unit level, the developers have knowledge of exactly what they are doing which helps in speeding up development.

• Clean code

Due to clarity, the resultant code is clean, simple, and well-designed.

• Clear documentation

Because of unit test creation, all the steps of software development are clearly documented.

• Fewer bugs

Because of continually testing each unit the software has fewer bugs overall.

• Tighter code

The continuous review of code helps reduces duplication of the code and improves the code organization.

What is Behavior-Driven Development (BDD)?

It is based on the same concept ad Test-Driven Development but goes a step higher. Moreover, it focuses on the functional testing of an application to see the expected behavior.

It is considered an extension of TDD in that it helps to test whether the units are working together.

BDD behavior description: Given, When and Then

In BDD the first step is defining the user story. This is done by gathering all stakeholders who together define it, which in turn forms the acceptance test. Below are definitions of a user story:

• As a

Defines a persona.

• I want

Defines the wants of a persona.

• So that

Define the benefit of including the feature

The team discusses the user story concretely with examples, ideas, and even concepts of the requirements and the expected behavior to capture the concepts in concrete terms that will form the criteria for the acceptance test. Below is the format the acceptance test is created:

• Given

This describes the stage of the user to the testing

• When

This is the action the user performs

• Then

Describes the expected system outcome.

Benefits of Behavior-Driven development (BDD) approach

• Shared understanding

There is a clear articulation of the user story which brings clarity on what is being developed and how each user story’s criteria are being met.

• Tests are re-usable

The same test can be used over and over to test behavior.

• Common language

With many stakeholders on board in BDD, a programming language is not used to describe the tests which improve communication because everyone is on the same page.

What is Acceptance Test-Driven Development (ATDD)?

ATDD involves different stakeholders. Plain language is therefore used like in BDD (for everyone to understand) to write acceptance tests based on the user story requirements. However, it’s more like TDD with acceptance tests being written before coding.

The acceptance tests are written based on the external point of view of the user and can be turned into automated acceptance tests.

It has similar benefits to BDD like a common language that improves communication and even shared understanding.

TDD vs BDD vs ATDD: Differences

Definition

• TDD

This is a technique in development that focuses on individual units of a feature that is desired.

• BDD

This is a technique of development that focuses on the behavior that is expected.

• ATDD

And this is a technique of development that is focused on the needs of the user is met.

Participants

• TDD

Developer

• BDD

Developers, QAs, Customers.

• ATDD

Developers, customers, QAs.

Language used

• TDD

Written in programming languages.

• BDD

Gherkin or Simple English

• ATDD

Gherkin/Simple English

Understanding tests

• TDD

Tests are written by developers for developers

• BDD

Tests are written for anyone to understand

• ATDD

The test is written for anyone to understand.

Focus

• TDD

Unit tests

• BDD

Understanding requirements

• ATDD

Writing acceptance tests.

Bugs

• TDD

Reduced likelihood and they can be easily tracked down.

• BDD

Can be more difficult to track down as compared to TDD.

• ATDD

There is more difficulty in tracking them down when you compare to TDD

Suitability

• TDD

Projects in that end users are not involved.

• BDD

The projects driven by user action.

• ATDD

Projects that emphasize on customer experience and with high competition.

Tools used

• TDD

JDave,Cucumber,JBehave,Spec,Flow,BeanSpec,Gherkin,Concordian,FitNesse,Junit,TestNG,frameworks,Nunit,Selenium tool.

• BDD

Gherkin, Specflow, Lettuce, Rspec, Cucumber, Concordian, Behat, Mspec, Selenium

• ATDD

Robot, Concordian, EasyB, Spectacular, FIT, Framework, FitNesse

Conclusion

Understanding how each of these methods works goes in a long way in helping developers and other stakeholders know which method will work for them in a particular project. For example, in an e-commerce project, you will find that BDD will be more suitable Or ATDD suitable for an app project, while TDD will be suitable for a project that doesn’t involve end users like servers or APIs.

The three frameworks both ensure that development teams are user-centered and focus on understanding what the user wants and a quality product is developed on time. The user requirements are also captured and tested at high (acceptance tests) and low levels (unit tests) to ensure quality applications are developed. A mix of methods can also be deployed to meet specific requirements efficiently.

To know more TDD vs BDD vs ATDD difference connect with Aalpha!