Is Jasmine BDD or TDD? Here’s What You Need to Know

There are plenty of opinions about software testing, but what exactly is it? First and foremost, it’s a process that’s designed to assure quality and verify that your application performs as expected. And software testing isn’t exclusive to just one language or framework. Today, we’re going to talk about software testing with Jasmine. More specifically, we’re going to answer whether Jasmine is BDD or TDD.

But to understand whether or not Jasmine is BDD or TDD, it’s useful to first get an overview of some testing concepts. The concepts to get familiar with are unit testing, TDD, and BDD. After we recap those concepts, I’ll identify if Jasmine is BDD or TDD and provide some examples to illustrate that.

Overview of Software Testing

Let’s go back to the basics for a minute and discuss what software testing is. Software testing is a process that ensures the software behaves as expected. Tests are considered “passing” when a given input to the system causes the result to match the expected program output.

One way to perform software testing is to operate a software program and ensure the program’s output matches an expected result. A quality assurance professional typically is responsible for software testing, but sometimes, depending on business circumstances, developers will also test software. If you’re curious about various automated testing tools, you can check out this post.

Now, let’s dive into unit testing, TDD, and BDD.

What Is Unit Testing?

At a high level, unit testing is testing that focuses on a small, logical piece of the system. As Martin Fowler points out in this article on unit testing, in practice, a team defines what constitutes a unit. How they define a unit depends on what type of software style they are using (e.g., object-oriented versus functional style).

For example, a suite of unit tests might cover the functionality of a calculator software module. In this hypothetical example, executing arithmetic functions is the sole purpose of the calculator module.

The Motivation for Unit Testing

Broadly speaking, a principal motivation for unit testing is to ensure that code can be maintained by future software developers. Let’s say a new software developer joins a team and wants to add new functionality to an application. Since the new developer isn’t familiar with all aspects of the application, they need a way to be sure that their additions won’t break existing functionality. Unit tests will provide that developer with a clear indicator if their new functionality is compatible with the existing application or not.

Now that you have an overview of unit testing, it’s time to move on to the next concept in testing, TDD.

What Is TDD?

While there are some strong opinions on how to do TDD within the software development community, there’s no disagreement on what it stands for: test-driven development.

In TDD, a developer will first write a test around a given piece of expected software functionality and ensure it fails. Then, they will write the minimum viable amount of code to make the test pass. Next, they can optionally refactor their code. They could also add some more tests to cover edge cases as their code evolves.

The Motivation for TDD

The motivation for TDD is to ensure a high level of test coverage as well as to ensure the code base is maintainable by future software developers. For example, if there were no tests and a new software developer joined the team, how would they automatically know if a new piece of software functionality they added broke existing functionality?

Does that example sound familiar? It should, since TDD is often applied to unit testing.

TDD Stakeholders

Typically, TDD is part of an agile development process. The basic idea behind agile is that developers are iterating their development in accordance with changing business needs. In common practice, the stakeholders in test-driven development are typically the software developers themselves. A software developer writes a failing test and then adds functionality that makes the test pass.

Now that you have an overview of test-driven development, it’s time to understand BDD. 

What Is BDD?

BDD stands for behavior-driven development. Like TDD, a practice of BDD is to write tests before writing the corresponding feature or features. The main difference between a set of BDD and unit tests is that typically BDD tests describe the behavior expected by the end-user. Note that this represents a higher level context than unit testing.

So, you might often see a BDD test suite that has tests that resemble the following:

Feature: User logs in
Scenario: User account already exists
Given the User enters an email and password
And the email is valid
And the password is valid
When the User presses the login button
Then the the User is taken to their profile page


Note that the above is an example of BDD specified using the Gherkin language, a common language used in the Cucumber framework.

The Motivation for BDD

Often, BDD is used as a collaboration of sorts between various business stakeholders (product owners, sales, marketing, etc.) and the engineering team. Since a BDD suite of tests defines expected end-user behavior, it’s a nice way to validate that you are building what the end-user wants (or at least what the business thinks the end-user wants) while getting test coverage at the same time.

BDD Stakeholders

Typical stakeholders include the development team and business representatives, such as product managers and sales and marketing folks.

How to BDD

The engineering team will typically sit down with various business stakeholders and flesh out the expected behavior of the system. The end result of this cross-communication may be a high-level specification as represented by the previously shown Gherkin document:

Feature: User logs in
Scenario: User account already exists
Given the User enters an email and password
And the email is valid
And the password is valid
When the User presses the login button
Then the the User is taken to their profile page

So now that you understand what TDD, BDD, and unit testing are, it’s time to understand Jasmine.

What Is Jasmine?

Jasmine is an open-source JavaScript testing framework developed by Pivotal Labs, a software consulting company.

Now, it’s finally time to answer the question that brought you to this post: Is Jasmine BDD or TDD?

The current home page of Jasmine says that it’s “a behavior-driven development framework for testing JavaScript code.” So the intent of Jasmine is to be a BDD testing framework, per its authors.

So, while the authors of Jasmine have intended it as a BDD testing framework, it can also be used with TDD and unit testing. Let’s look at some usage examples.

Using Jasmine With BDD: An Example

Let’s start with an example of using Jasmine with the testing strategy the Jasmine authors intended it to be used with: BDD. The code below shows a BDD test suite describing expected system behavior from the end user’s point of view.

describe("VideoPlayer", function() {
    var videoPlayer;
    // hook before each test
    beforeEach(function(){
        videoPlayer = new VideoPlayer();
        spyOn(loadingSpinner,'show'); // intercept and record calls to loadingSpinner.show
        videoPlayer.play();
    });

    // some example specifications and corresponding tests
    it('shows a loading spinner indicator',function(){
        expect(loadingSpinner.show).toHaveBeenCalled();
    });
    it('plays',function(){
        expect(videoPlayer.isPlaying).toBe(true);
    });
});

Notice how the tests above describe how the system would function as if the end user were experiencing it. This underlies the essence of BDD testing.

Using Jasmine With Unit Testing and TDD: An Example

Even though the Jasmine website tells us that Jasmine is a BDD framework, you can also use it with TDD and unit testing. Let’s look at an example.

describe('Calculator', () => {
  // A jasmine unit test specification
  it('should be able to add two whole numbers', () => {
    expect(Calculator.add(3, 3)).toEqual(6);
  });

  it('should be able to add a whole number and a negative number', () => {
    expect(Calculator.add(4, -1)).toEqual(3);
  });

  it('should be able to add a whole number and a zero', () => {
    expect(Calculator.add(55, 0)).toEqual(55);
  });
});

The unit testing example above is fairly trivial, but it shows you the syntax of the Jasmine framework. It also shows that you could use Jasmine for unit testing, rather than BDD. You can see there is a human-readable syntax with keywords such as “describe,” “expect,” and “toBe.”

So Is Jasmine BDD or TDD?

Although Jasmine was written as a BDD framework by its authors, hopefully, the examples I shared have shown that you can use it for a different style of testing. Whether you prefer BDD or TDD, the most important thing is to test your software. Your future self and teammates will thank you for making software that’s stable and easier to add features to.

And if you’re new to Jasmine, check out this helpful article on Jasmine testing on the Testim blog.

This post was written by Bruce Park. Bruce started out as an engineer in the automotive space. From there, he moved on to become a software engineer at various startups on the west coast of the United States–working on both backend and frontend systems. In addition to his day job, he contributes to open-source libraries such as ESpec, a BDD testing framework written in Elixir. When he’s not sitting in front of the computer, you can find him swimming or enjoying a fresh cup of coffee.