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!