Have you ever wondered about the differences between unit testing and TDD? Or TDD and Test-First? Or even the relationship of all of this to the agile methodologies? Are these kinds of tests manual or automated? And, for goodness’ sake, what is it with all the “DD”-ending acronyms?
If the paragraph above accurately describes you and your relationship with these topics don’t despair because we’ve got your back. Today’s post is your guide to the different testing techniques and methodologies available.
After reading this article, you will:
Let’s get started.
It may come as a surprise to some of you that I even felt the need to add such a section. If that’s the case for you, feel free to skip it. Believe it or not, there are many developers for whom the notion of automated software testing is completely alien.
If you go to Wikipedia, you’ll see that the topic of automated software testing is huge. Really, really huge. There are many different kinds of automated testing, each one of them catering to some specific need or even audience.
Nowadays, when people talk about automated testing (or simply testing), more often than not they mean unit testing, which many people consider to be the most important type.
There are many possible and somewhat conflicting definitions for unit testing. I particularly like Roy Osherove’s definition:
A unit test is an automated piece of code that invokes a unit of work in the system and then checks a single assumption about the behavior of that unit of work.
Let’s try to parse this sentence. Roy starts out by claiming that “a unit test is an automated piece of code.” In other words, it’s a program. A unit test is an automated test. It’s a program that tests your program!
Let’s move on. The definition goes on to state that a unit test “invokes a unit of work in the system.” Let’s not worry for now about what a unit of work is; instead, focus on the word “invokes.” Our automated unit test invokes whatever it’s testing: no human intervention is needed.
Finally, we see that the unit test then “checks a single assumption about the behavior of that unit of work.” Again, don’t worry about what a unit of work is or isn’t. Instead notice that, once again, no human intervention is needed, since the test itself checks its result.
What can we get from this definition? In short, a unit test is a program that:
And how does all of that work in practice? In short, we can say that you write and run unit tests with the help of a test framework. In the Java world, for instance, the most well-known test framework is JUnit, while in .NET-land you’d probably use NUnit or xUnit.net.
And What About the Unit?
In the previous section, I kept telling you not to worry about what the unit (or “unit of work,” as Roy Osherove puts it) means in the context of unit testing. Now it’s time to worry. So…what is this unit thing?
Well…it’s kind of hard to say. One of the most controversial things about the whole unit testing thing is the definition of a “unit” itself.
This is what Wikipedia has to say about the issue:
Intuitively, one can view a unit as the smallest testable part of an application. In procedural programming, a unit could be an entire module, but it is more commonly an individual function or procedure. In object-oriented programming, a unit is often an entire interface, such as a class, but could be an individual method.
And what about Roy Osherove’s definition? Let’s see:
A unit of work is a single logical functional use case in the system that can be invoked by some public interface (in most cases). A unit of work can span a single method, a whole class or multiple classes working together to achieve one single logical purpose that can be verified.
In my view, what all of those definitions have in common is that they’re somewhat vague. It doesn’t sound that useful to me to go to a beginner and say: “What is a unit? Easy: a unit is a class, except when it’s just a method. Oh, I forgot to mention: it can also be a group of several classes.”
For that reason, I tend to say that a unit is just a method of the class under test. It might be somewhat reductionist, maybe not totally correct, but it sure is pragmatic. And of course: your definition doesn’t have to remain the same forever. It can—and should—evolve as you learn and gain more experience with all of this.
TDD means Test Driven Development. It’s a software development methodology in which unit tests are used to drive the development of the application.
TDD was created/rediscovered by Kent Beck, who released Test Driven Development: By Example in 2002. TDD has gained a lot of popularity since then, in part due to being one of the key engineering practices of the Extreme Programming methodologies.
Great, but How Does TDD Work?
The process of applying TDD is itself very simple. You should write code following what’s called the “red-green-refactor” cycle:
Proponents of TDD claim that by following this process you’ll achieve a simpler design, creating modules that are by definition low coupled and having more confidence to make changes to the code in the future, since you’ll have an automated test suite covering all of the code.
BDD means Behavior-Driven Development and was introduced in 2006 by Dan North. Dan states that BDD evolved as a response to TDD, an attempt to address issues he had when trying to apply the TDD process.
BDD emphasizes the need to include not only software developers but also non-technical people, such as business analysts, in the process of defining the tests. By the way: the term “test” itself isn’t that welcome anymore. Under the light of BDD, we should think of requirements. Requirements should follow the template:
By using a dedicated tool (such as Cucumber, JBehave, or Specflow), it’s possible to turn requirements written in this format into a test skeleton.
How do all of these pieces fit in the puzzle? What are the relationships between all these things?
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
All three of the techniques (but especially unit testing and TDD) presented in today’s post remain more or less controversial to this day. See some examples:
Are these techniques worth your time? My personal opinion has changed over the years but my current take is: write automated tests for your code. Mostly unit tests, but also other types (while being aware that there might be exceptions to that rule). The process that you use in order to write said tests shouldn’t matter that much.
Are TDD and BDD worth your time? Definitely. Do they also provide challenges and have their own shortcomings and limitations? Of course. There’s no silver bullet in our industry. The only way is to read a lot and practice a lot in the hopes that, when the time comes, you’ll be able to make informed decisions. Read more on testing techniques like unit testing, TDD, and BDD.
Help us improve this page!
What problem are you trying to solve?
Read more about how the QA team at ELEKS evaluated different test management solutions and why they ultimately chose TestRail.
This post covers how to show test coverage, manage requirements traceability, and create a traceability report in Jira.
Learn about the pros/cons of using Jira as a test management solution, alternatives, & how teams that use Jira manage their testing.