Maybe it's just my luck. But whenever I talk to developers with whom I have to collaborate, inevitably there is some misunderstanding as to the definition of a unit test vs TDD vs BDD. The topic also seems to be the source of serious pushback from developers.
Why Some Developers Don't Like Testing
The main reason this issue comes up is that the word “test” seems to create a Pavlovian-like response in some developers to automatically tune you out, thinking “Oh he/she said the word test—that's the job of a test engineer. Not me.”
It can be pretty bothersome when a QA test engineer starts getting resistance from developers when they ask them questions like “Have you created unit test for your code?” and “Are you using Test Driven Development?” The issue only intensifies if you don't understand these key concepts yourself.
Also –you'll have a hard time convincing a developer why they need to do something if there isn't a solid understanding between everyone on the team of what these terms mean.
So for the folks out there that are facing the same confusion or resistance within your organizations, I hope this helps.
Unit Testing Vs Integration Testing
Okay … I would think this would be a fundamentally-understood concept, but at one company I worked for, they used the word “unit testing” to mean something completely different then what most programmers consider it to be.
Unit testing is testing the smallest single amount of code or discreet behavior as possible; usually at a method level. A unit test shouldn't have any dependencies on anything external, such as other methods or APIs. The reason for not having dependencies on anything else is that if the unit test fails, it's easy to know where it failed. Think of a single Lego block.
When you start combining two or more pieces of logic together, it gets you into integration testing. Think of combining multiple Legos blocks together.
Test-Driven Development (TDD) Vs Behavior-Driven Development (BDD)
Test-Driven Development (TDD) uses tests as a way to design code by creating the test first before any actual production code is written. You then try to make the test pass by creating production code that fulfills the test. This is usually a five-step process:
- Write a test (some also call this a specification).
- Run the test and show that it fails. (red)
- Write the smallest amount of production code possible that meets the needs of the test.
- Run the test until it passes. (green)
- Refactor.
This process is sometimes called red-green-refactor. Red symbolizes fail and green represent pass.
In theory, this approach helps force the developer to think about how to design a system and to make the system easily testable. Notice that the tests are written from the perspective of a developer.
What is Behavior-Driven Development BDD?
While TDD can be considered a low-level approach, BDD is more of an Agile “as a user” approach. Basically, you're writing a test as stories. The focus is on the user.
BDD involves creating features that contain scenarios that are meant to test behaviors that your application should have. This is all done completely from the view of a user. Tests are expressed by creating examples that anyone — not just developers — can read.
Because this approach avoids getting caught up in low-level implementation details, like how something is going to be done, it forces you to instead focus on what your customer really wants. Since tests are written in English-like syntax, it is also easier to get feedback from everyone on your team, as well as your customers. Customer feedback is critical because it helps to ensure that you're actually building what they want before writing any code.
BDD does not replace TDD, but instead builds upon it.
The best way I can explain the difference between TDD and BDD is to think of white box testing as opposed to black box testing. You want to focus on both when testing an application, but the two are used from completely different perspectives.
What is White Box Testing?
White box testing focuses on activities that require you to actually know the underlying source code of a program. Because the developer has written the code, he or she should understand it and have the ability to modify and test the actual code directly.
What is Black Box Testing?
Black box testing is the opposite. When performing black box testing activities, you are treating the program as a literal black box — meaning that you can't see into the actual source code of a feature, nor would you necessarily understand the underlying code of a particular feature. You act is if you have no idea how the program should work.
What does this have to do with TDD and BDD?
I've found that one of the best ways to for a tester to understand the difference between TDD and BDD is to draw a comparison against something they already know –white box and black box testing. So, think of TDD as a white box testing activity that is done by a developer.
BDD testing is more of a black box activity, so anyone should be able to create BDD tests. Since BDD is more similar to black box testing, you're taking the perspective of an actual user of the system who doesn't need to know (or care) about the underlying code. What they care about is the feature it delivers to help them do their job quickly and effectively.
Unit, TDD and BDD Testing Wrap up
Well, those are a few terms that I've found some test engineers struggle with. I hope it gives you a better understanding of the differences between Unit Testing, Test-Driven Development, and Behavior- Driven Development.
