How to write your first test in JavaScript

Debugging is often the most frustrating part of programming, and there’s a reason for that. We’ve all been there: you make a small change to your code, and suddenly everything breaks. You might think you’re wasting time for no good reason, but in reality, your time is being swallowed by the rabbit hole of unnecessary complexity. So, let’s break this down. Why does this happen?

The root of a significant debugging headache usually stems from not fully understanding the code base. When you dive into unfamiliar territory, every little change can have a cascade effect that’s hard to predict. This is why code should be as straightforward as possible. If you can simplify your design, you can avoid confusion, and no one will get lost chasing down bugs.

Let’s say you’re working with a function that manipulates some data. If the function is convoluted, tracking down where things went wrong can take hours. That’s where well-structured code comes in. Here’s a simple example:

function addNumbers(a, b) {
  return a + b;
}

Now imagine if your function was buried in layers of abstraction without clear naming conventions. You’d end up spending more time interpreting each layer rather than focusing on the functionality. It’s like navigating a maze where no signs point you in the right direction.

Moreover, the tools you choose to debug can also create roadblocks. A poorly configured IDE can slow you down, especially if it fails to catch errors in real-time. Take advantage of built-in debugging tools in your development environment. They’re there to help you diagnose issues faster.

For instance, using breakpoints can drastically reduce the time spent on debuggings. When you set breakpoints, you can pause execution and inspect the state of your application at any point. Here’s a quick example of how you might set a breakpoint in your code:

debugger; // This line will pause execution in supported environments
function multiplyNumbers(a, b) {
  debugger; // Set a breakpoint here
  return a * b;
}

The key here is to identify the right points to inspect your code. The debugger gives you a snapshot of the variables at that moment. This means you can catch the state of things when they aren’t working as expected.

Another common reason for prolonged debugging is the lack of comprehensive unit tests. Without them, you’re essentially guessing what might break when you make a change. Think of unit tests as your safety net. They allow you to modify your code with confidence, knowing that if something goes wrong, you’ll be alerted immediately.

For example, consider a simple unit test for the earlier addNumbers function:

describe('addNumbers', () => {
  it('should return the sum of two numbers', () => {
    expect(addNumbers(1, 2)).toBe(3);
  });
});

By implementing tests like these, you’ll quickly get feedback on the functionality, which reduces the overall time spent on debugging. It’s a preventive measure that pays dividends over time. Now, thinking beyond just the immediate functionality, let’s dig into what makes a good testing strategy and what you should focus on testing…

The world’s simplest test and the tools you need to run it

So let’s talk about the simplest test in the world. Forget about mocks, spies, and stubs for a minute. Forget about integration tests, end-to-end tests, and all the other fancy labels. The simplest, most fundamental test you can write follows a pattern so obvious it’s almost embarrassing to name it: Arrange, Act, Assert.

That’s it. Three steps. First, you arrange the world to be exactly the way you need it for your test. This means creating any objects, variables, or inputs your function will need. Second, you act. You call the one specific function you’re trying to test. Third, you assert that the world has changed in the way you expected. Did the function return the right value? Was a specific variable modified? This isn’t rocket science, it’s just basic scientific method applied to code.

Let’s use that addNumbers function again. You might look at it and think it’s too simple to test. You would be wrong. Building the habit and the infrastructure to test the simple things is what makes it possible to test the complicated things later. Here’s how you’d write a test for it using the Arrange, Act, Assert pattern explicitly.

describe('addNumbers', () => {
  it('should correctly sum two positive numbers', () => {
    // 1. Arrange
    const num1 = 5;
    const num2 = 10;

    // 2. Act
    const result = addNumbers(num1, num2);

    // 3. Assert
    expect(result).toBe(15);
  });
});

Of course, you can’t just write this code in a file named my-test.js and expect it to magically run. You need a couple of basic tools. The first is a test runner. A test runner is a program whose only job is to find all your test files, execute them, and give you a report on what passed and what failed. For modern JavaScript, Jest is the de facto choice. You install it, add a single “test” script to your package.json, and you’re done. It’s smart enough to find your test files automatically.

{
  "scripts": {
    "test": "jest"
  },
  "devDependencies": {
    "jest": "^29.5.0"
  }
}

The second tool you need is an assertion library. This is what provides the expect() and .toBe() functions. You *could* write your own assertions with if (result !== 15) throw new Error('Test failed!'), but you’d be wasting your time. A good assertion library like the one built into Jest gives you a rich, readable vocabulary to describe your expectations. More importantly, when an assertion fails, it gives you a fantastically useful error message. It will tell you exactly what it expected to see and what it actually got. This is the whole point. It pinpoints the failure for you.

Let’s see this in action. Imagine you, or a less-caffeinated future version of you, introduces a bug into the addNumbers function.

function addNumbers(a, b) {
  return a + b + 1; // An off-by-one error, the classic.
}

When you run npm test, you won’t get a cryptic error. You’ll get a beautiful, color-coded report that tells you exactly what’s wrong. It will look something like this, telling you that it expected 15 but received 16. This immediate, precise feedback loop is what saves you from hours of painful debugging. It transforms the process from “hunting for a needle in a haystack” to “the computer is pointing directly at the needle for me.” This is how you stop wasting time. You’re not just testing; you’re building a system that finds bugs for you, automatically, before they ever make it to your users.

Now you know how to test so let’s talk about what to test

Now that you have the tools and the basic pattern, the real question becomes: what should you actually test? It’s easy to get overwhelmed. Should you test every single function? Every line? The answer is a pragmatic “no.” Your goal isn’t 100% code coverage, a metric that sounds impressive but often leads to writing useless tests just to make a number go up. Your goal is to have confidence that your code works and won’t break unexpectedly. The secret to achieving this is to focus on the boundaries, the tricky spots, the “edge cases.”

Think about any piece of code you write. It has its “happy path,” the straightforward case where everything is normal. For our addNumbers function, that was adding 2 and 3. That’s the first thing you test, always. But the real bugs, the ones that take down servers, don’t live on the happy path. They lurk in the shadows of the edge cases.

Let’s take a slightly more interesting function. Imagine you have a function that truncates a string to a certain length, adding an ellipsis if it’s cut short.

function truncate(text, length) {
  if (text.length <= length) {
    return text;
  }
  return text.slice(0, length) + '...';
}

The happy path is easy: give it a long string and see if it gets truncated. But what are the edges? What are the inputs that might break things or reveal a faulty assumption in your logic?

Here’s a starting list of what you should be thinking about:

• The “nothing” case: What if the text is an empty string? truncate('', 10)
• The “exact fit” case: What if the text length is exactly the target length? truncate('hello', 5)
• The “just under” case: What if the text is one character shorter? truncate('hell', 5)
• The “just over” case: What if the text is one character longer? truncate('hello world', 5)
• The “zero” case: What if the target length is 0? truncate('hello', 0)

Each of these represents a boundary condition where the logic is likely to shift from one branch to another. These are the most fertile grounds for bugs. Writing tests for these cases isn’t just about finding bugs; it’s about forcing yourself to define exactly how your code should behave in these specific situations. Does truncating to a length of 5 mean you get 5 characters plus an ellipsis, or 5 characters total? Your tests answer and enforce these questions.

describe('truncate', () => {
  // The happy path
  it('should shorten a long string and add an ellipsis', () => {
    expect(truncate('This is a very long string', 10)).toBe('This is a ...');
  });

  // The edge cases
  it('should not change a string that is shorter than the length', () => {
    expect(truncate('Short', 10)).toBe('Short');
  });

  it('should not change a string that is exactly the length', () => {
    expect(truncate('Exactly', 7)).toBe('Exactly');
  });

  it('should return an empty string with an ellipsis if length is 0', () => {
    expect(truncate('hello', 0)).toBe('...');
  });

  it('should handle an empty string as input', () => {
    expect(truncate('', 5)).toBe('');
  });
});

Look at that last test for a length of 0. Running it against our original function reveals a bug! It would return '...', which is 3 characters long, not 0. Our test has just uncovered a flawed assumption. We’re forced to fix the code and, more importantly, we now have a regression test that prevents this bug from ever creeping back in. This is the power of testing the edges. You’re not just checking for correctness; you’re building a safety harness for future development.

How do you explain this concept? Is there a different mental model you use to teach what to test first?