Writing Test Cases — Write simple test cases for functions using assertions (conceptual)

Imagine you build a calculator app for a class project. It works perfectly on Monday, but after you add a new feature on Tuesday, the addition function suddenly returns wrong answers. You didn't mean to break anything — you just didn't have a way to automatically check that your old code still worked. This is exactly the problem that test cases solve. A test case is a small piece of code that runs your function with known inputs and checks whether the output matches what you expect.

The idea of automated testing has evolved over decades as software grew more complex. Early programmers tested their code by manually running it and checking the output with their own eyes. As programs grew from hundreds to millions of lines, manual testing became impossible. Developers needed machines to do the checking for them, which led to the concept of assertions — statements that declare "this condition must be true, or something is wrong."

The core question that testing answers is deceptively simple: "Does my function actually do what I think it does?" Without test cases, you're relying on hope. With them, you have proof.

Before writing test cases, you need to understand a few foundational ideas. A test case is a small, self-contained piece of code that calls a function with specific inputs and checks whether the output matches the expected result. An assertion is the actual check — a statement that says "I assert this condition is true." If the condition is true, the test passes silently. If it's false, the test fails loudly, alerting you to the problem.

The diagram above illustrates the Arrange-Act-Assert pattern (sometimes called AAA), which is the most common way to structure a test case in any programming language. In the Arrange step, you set up the inputs and any data your function needs. In the Act step, you call the function and capture its return value. In the Assert step, you use an assertion to compare the actual return value against the expected value. If they match, the test passes quietly. If they don't, an error message tells you exactly what went wrong.

JavaScript gives you several ways to write assertions. The simplest is the built-in console.assert() method. It takes a condition as its first argument and an optional error message as its second. If the condition evaluates to true, nothing happens — silence means success. If the condition evaluates to false, the message is printed to the console as an error.

console.assert() Syntax

You can also write your own simple assertion function. This gives you more control over the output and helps you understand what's happening under the hood. Here's the basic logic:

A critical detail is the use of strict equality (===) rather than loose equality (==) in your assertions. Strict equality checks both the value and the type, which prevents subtle bugs. For example, 5 == '5' is true in JavaScript (loose equality coerces types), but 5 === '5' is false (strict equality does not). Always use === in your test assertions to catch type-related bugs.

A single test case only tells you about one specific input. To gain confidence that a function truly works, you need to write multiple test cases covering different scenarios. Think of it like studying for a test — reviewing just one practice problem isn't enough. You need to practice with normal cases, edge cases, and error cases.

Normal cases test the everyday, expected behavior. These are the inputs your function was primarily designed to handle. Edge cases test the boundaries — zero, negative numbers, extremely large values, or the first and last items in a list. Error cases test what happens when someone passes the wrong type of data or missing values. A function that handles all three categories gracefully is a robust function.

• ✓ Normal cases — Test with common, expected inputs that represent typical usage.
• ✓ Edge cases — Test with boundary values like 0, empty strings, and negative numbers.
• ✓ Error cases — Test with invalid inputs like wrong data types, null, or undefined.

Let's walk through a complete example. Suppose you write a function called getLetterGrade(score) that takes a numerical score (0–100) and returns a letter grade: 'A' for 90–100, 'B' for 80–89, 'C' for 70–79, 'D' for 60–69, and 'F' for anything below 60. We'll write a full set of test cases using assertions.

Assertion-based testing is a powerful tool, but like any tool, it has both strengths and limitations. Understanding these will help you use assertions effectively and know when to reach for more advanced testing approaches.

The conceptual assertions you've learned here are the foundation for every professional testing framework. When you're ready to level up, tools like Jest, Mocha, and Jasmine provide richer assertion libraries, automatic test discovery, detailed reports, and the ability to test asynchronous code. But the core idea remains the same: call a function, check the result.

Notice how Jest's expect(x).toBe(5) reads almost like English: "expect x to be 5." This is the same concept as console.assert(x === 5) — just wrapped in a more descriptive and powerful syntax. Once you understand assertions conceptually, transitioning to Jest or any other framework feels natural because you already know the core pattern: arrange, act, assert.