Behavior-Driven Development and Test-Driven Development
Test Driven development (or TDD) is the development of software that uses a series of tests, written by the developer, to confirm whether or not the software is functioning correctly.
In TDD, the developer begins with a goal, and then writes code that defines the expectations that need to be met in order for that goal to be achieve before any code is written. After the test is written, the test is then ran to ensure that it fails.
This is done to confirm that the test is written correctly. If the test passes then the desired code has already been written, and therefore the desired outcome is already present, or else the test code has been written poorly.
Once the test is written, and the code is written that satisfies that test, it’s time to refactor.
Refactoring is done in part to conform the code to best practices, as well as to make the code more concise, easier to read, and explicit.
The process is as follows:
- Add a test
- Run all tests and see if the new one fails
- Write some code
- Run tests
- Refactor code
- Repeat
Test driven development allows for you to set up a series of conditions that you want to meet, while having verifiable evidence that you’ve done so. If the test is written correctly, then only correct behavior can pass the test. Since this code is written to ensure that it only passes the test, TDD allows the developer to guide development in a logical, incremental way. This way, you can add features to your code piece by piece, while ensuring that they function correctly together.
Write a test to test a specific aspect of your code. Write a test for the code to “pass.” Then run that test to ensure that it fails. If the test passes without any code having been written, then the new desired functionality is unnecessary, or else the test has been written poorly. If the test failed, then write some code in an attempt to pass the test. Did it work? If so, then great! The code is working and on to the next thing. If not, then you need to do some more work. The last step is refactoring which is made to make the code run more smoothly, while making it more readable for future developers.
So What is BDD?
So what is Behavior driven development? Simply put it is development that emphasizes the behavior of the software as seen by the user, rather than the functionality seen by the developers writing and passings tests.
The main thing to take away from an initial pass over the concept of Behavior Driven Development is that it is an outside-in method of developing software. The “behavior” matters more in this style than simply passing a series of tests. What does the user experience when they’re interacting with the finish product? What should they experience?
Because of this focus, instead of beginning with a series of tests created in order to test the existence and functionality of certain code, the software development process in BDD begins with a series of goals viewed from the perspective of the user, which may be familiar to some as “user stories.”
“As a user, I want to be able to add a cat to my page.”
“As a user, I want to be able to ‘trade’ that cat with another user.”
By using these stories to drive development, more people can be brought in to explain what their desired outcome of the product should be. The stakeholder of the software and the developer can work together in a more cooperative manner to describe the desired design of their product. In order to agree on what the project should end up looking like, both the developers and the stakeholders need to put themselves more in the position of the person who is using the app, and design from their perspective.
Because the goals are articulated in plain English rather than in code, more people can be brought in to brainstorm what the software can and should do.
Here is a brief example taken from one of my resources, based on Spotify:
Scenario 1:
Given that Childish Gambino has licensed — condition
And the user is a subscriber of the Spotify service — condition
When Spotify subscriber selects “Because The Internet” album by Childish Gambino from the Spotify Catalog — when the event is triggered
Then Spotify service will stream “Because THE Internet” album by Childish Gambino from the beginning for the user — Expected outcome
(Credit to: https://www.ca.com/en/blog-agile-requirements-designer/guide-to-test-driven-development-tdd-vs-bdd-vs-atdd.html)
By emphasizing user experience both the investors and the developers have a clear goal of what they are trying to achieve in readable pseudo-code at the very beginning of the development process.
So what are the pros and cons of each method?
TDD is modular, each series of tests verifies that a specific component is either working or failing, and with a series of green lights for certain tests it’s easy to understand which parts of your code are or aren’t working. This represents good modular design, as its easier to verify which parts of the code do what, as well as which parts of the code work, or don’t as the case may be.
On the other hand, if tests are poorly written, it is very likely that the code will be as well.
BDD in many cases uses much of the same framework as TDD, but again benefits from having a clearer set of goals, and a clearer, more open, style of communication between the people funding a certain app, and the people who are actually writing it. A high-order list of goals and objectives allows everyone involved in the development process have an understanding of the goal of the project day-today.
The largest drawback of BDD it seems is that the more voices there are in the room, often the harder it is to reach a genuine consensus about what the next step should be. It’s easy for everyone to have an idea of certain flaws involved in a project, but it’s a lot harder to come up with a solution, especially when they don’t the skill set to tackle those problems.
While both TDD and BDD use tests to drive development, BDD takes a particular emphasis on designing from the user, or the stakeholder’s perspective. TDD relies far more on a top-down version of decision making, while BDD is slightly more horizontal in its approach, and requires on all parts of the team having a clear idea of the desired behavior of the application before implementing code.
Sources:
