What are test cases and test assertions in Unit Testing?

Updated Feb 20, 2026

Short answer

A test case is a small, repeatable scenario that verifies a specific behavior of code. It defines inputs, actions, and expected outcomes. A test assertion is the statement that checks whether the actual result matches the expected result.

Deep explanation

A unit test is built around a question: “Does this small piece of code behave correctly for this situation?” A test case provides the situation, while an assertion provides the verification.

A test case usually contains three parts:

Setup: Prepare the required data, objects, or dependencies.
Execution: Run the unit being tested.
Verification: Use assertions to compare actual behavior with expected behavior.

A test case describes what you want to prove; an assertion proves whether it happened.

For example, a test case for a calculateDiscount function might say:

Given a customer spends 100 units.
When the discount function runs.
Then the result should be 10 units.

The assertion is the final check: “Is the returned discount equal to 10?”

discount.test.ts

TypeScript

1test("applies a 10 percent discount", () => {
2  const total = calculateDiscount(100);
3
4  expect(total).toBe(10);
5});

Here, the test case is the complete test scenario. The assertion is expect(total).toBe(10), which compares the actual value with the expected value.

How assertions work

Assertions are provided by testing frameworks such as Jest, JUnit, or pytest. They fail the test when the condition is false, giving developers feedback about what behavior is incorrect.

Common assertion types include:

Assertion	Purpose	Example
Equality	Checks matching values	`expect(result).toBe(5)`
Truth check	Checks a condition	`expect(isValid).toBe(true)`
Exception check	Checks errors	`expect(() => run()).toThrow()`
Collection check	Checks contents	`expect(items).toContain("A")`

A good unit test normally has a clear reason for failing. If a test has many unrelated assertions, it becomes harder to understand which behavior broke.

Rendering diagram…

Test cases versus test assertions

These terms are related but not interchangeable.

Concept	Meaning	Scope
Test case	Complete scenario being tested	Larger
Assertion	Individual verification inside a test	Smaller
Test suite	Group of related test cases	Collection

A single test case can contain multiple assertions, but too many assertions can make the test fragile. For example, testing both a user's name formatting and payment calculation in one test mixes unrelated behaviors.

⚠️ A strong unit test should fail for one clear reason.

Interviewers often look for whether a candidate understands that tests are not only about checking code output. Good tests document expected behavior, prevent regressions, and give confidence when code changes are made.

Real-world example

Imagine an e-commerce application with a calculateShipping function. A developer creates a test case for free shipping when an order exceeds 50 units.

shipping.test.ts

TypeScript

1test("returns free shipping for large orders", () => {
2  const shipping = calculateShipping(75);
3
4  expect(shipping).toBe(0);
5});

The test case defines the customer scenario: an order value of 75. The assertion verifies the business rule that shipping should cost 0.

Rendering diagram…

If a future code change accidentally charges shipping again, this test fails and highlights the broken requirement.

Common mistakes

* **Too vague** - Writing tests without a clear behavior makes failures difficult to understand
test one specific outcome instead.
* **Testing implementation details** - Checking internal variables or private methods creates brittle tests
verify observable behavior.
* **Weak assertions** - Running code without meaningful checks does not prove correctness
always assert the expected result.
* **Too many checks** - Combining unrelated behaviors in one test hides the real failure
keep test cases focused.
* **Ignoring edge cases** - Testing only the happy path misses failures
include invalid inputs and boundary values.

Follow-up questions

What makes a good unit test?
What is the difference between a test case and a test suite?
Why should unit tests avoid testing implementation details?
How many assertions should a unit test contain?