Chapter 1. Intro to Testing

What Is Software Testing?

In short, you can test software against a specification.

Let’s say you’re writing a simple calculator that just does addition. Before you even start, think about how it should behave. It should be able to add positive integers. It should be able to add negative integers. It should be able to add decimal numbers, not just integers. You can think of many different ways that your calculator needs to work.

Before you’ve written any of the code, you know how you want it to behave. You have a specification for its behavior.

You can write these specifications in code. You’d say, “OK, it should work this way.” You’d make tests that added 1 and 1, 2 and 2, –1 and 5, –1.2 and 6.8, 0 and 0, and so on. When you run these tests, you’ll either get a success (it works according to the specification) or a failure (it doesn’t). If you ran all of your tests and saw success for each, then you can be pretty sure that your calculator works. If you ran these tests and saw some failures, then you know that your calculator doesn’t work.

That’s software testing in a nutshell. You’re testing your code against a specification. There are many tools (Jasmine among them) that help you automate these software tests.

It’s important to know that it’s difficult (and often impossible) to write tests for every case. In the calculator example, there are an infinite number of possible combinations. When testing, you should try to cover every reasonable case by testing a number of different groups (integers, negative numbers, mixes of the two, etc.). You should also identify boundary conditions (zeroes, for example) and edge cases, testing as many different scenarios as possible.

Why Is It Useful?

Testing is useful for a number of reasons.

First, these tests can evaluate a program’s correctness after a change. Let’s say all the tests are passing, and then I decide I want one of my functions to be faster. I can dive in, make some changes, and see that it is indeed faster. But if I run the tests again and see that some are failing, I quickly discover that my fix has broken some part of the code. Automated testing lets me see those errors before they happen in the “real world.”

These tests can also function as good examples for other developers. If a developer is trying to figure out how to use some undocumented part of your code, a well-written test can help him see how that piece works.

Test-Driven Development

A relatively new software development technique is called test-driven development, or TDD. The process works like this:

  1. Write test cases for a specific part of your code. In the calculator example, you’d write tests for adding positive numbers, negative numbers, integers, and so on. You haven’t written the calculator yet, so all of these tests should fail!
  2. Write your code to “fill in” the tests. Your code only serves to make all of your tests pass, and nothing more.
  3. Once all of your tests pass, go back and clean up your code (this is called refactoring).

Test-driven development allows developers to think clearly about the specifications before their minds are clouded with the implementation details. It also ensures that tests are always written, which is always useful.

Behavior-Driven Development

With behavior-driven development, or BDD, you write specifications that are small and easy to read. There are basically two key parts of BDD:

  1. Your tests must be small and test one thing. Instead of testing the entire application, you write many small tests. In the calculator example, you would write one test for each addition pair: one test for 0 + 0, one test for 1 + 1, one test for –5 + 6, one test for 6.2 + 1.2, and so on.
  2. Your tests should be sentences. In the calculator example, sentences would look like “Calculator adds two positive integers.” The testing framework that you use (Jasmine, in this book’s case) should do this automatically for you.

These two tenets allow you to run your test suite and see exactly what’s wrong at a glance. If you see a bunch of successes but one failure on “Calculator adds two negative numbers,” you know where to look.

Note

Dan North is credited with BDD’s invention. He describes the system in more detail on his website.

So, enough about testing. What’s Jasmine?

Get JavaScript Testing with Jasmine now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.