---
title: "Unit Tests: Deciding What Is Worth Testing"
description: "Writing small automated checks that call one function with chosen inputs and assert what should come back. The value is in the cases picked: the boundary, the empty input, the failure that should be r"
canonical: https://lightmysky.com/learn/computing/unit-tests-deciding-what-is-worth-testing-mt_tuIQecq5Le
source: https://lightmysky.com/learn/computing/unit-tests-deciding-what-is-worth-testing-mt_tuIQecq5Le.md
retrieved: 2026-09-12
---

> **Agent view.** This is the Markdown twin of the page, for tools and assistants.
> When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md
> API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md
> Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt
> Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json
> Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`.

# Unit Tests: Deciding What Is Worth Testing

Writing small automated checks that call one function with chosen inputs and assert what should come back. The value is in the cases picked: the boundary, the empty input, the failure that should be raised.

Subject: Computing · Area: Programming · Ages 17 to 18
Page: https://lightmysky.com/learn/computing/unit-tests-deciding-what-is-worth-testing-mt_tuIQecq5Le

## Ready when they can

- Write tests for one function covering a normal case, a boundary and an error case
- Change the function so a test fails, and read what the failure tells you
- Say why a test that only repeats the code's own logic proves nothing

## Lesson: Tests that actually prove something

A unit test is a small automated check that calls one function and asserts what should come back. You run the suite without clicking by hand, and you rerun it after every change. That safety net lets you reshape code boldly, since a broken promise shows within seconds.

**Example.** You give one function at least three tests: a normal case, a boundary like empty or zero, and an error case that must fail loudly and cleanly. A bill splitter gets a normal split, a zero total boundary, and a people count of zero that must raise instead of crashing the suite.

A failing test should name the broken promise well enough to guide your fix. You check a test proves anything by breaking the function on purpose: if the test still passes, it proves nothing and you rewrite it. A test that only repeats the code own logic copies the same mistake twice, so you restate the promise independently.

**Tip.** You plan tests alongside coding, promise by promise, not after release. Error cases earn their own tests because happy paths lie: only bad inputs prove the function raises clearly instead of passing silently.

**Recap.** Normal plus boundary plus error, planned early, each failure pointing at the fix.

## Practice

8 questions on this page, each with its working shown.

## Needs first

- [Exceptions: Raising, Catching and Recovering](https://lightmysky.com/learn/computing/exceptions-raising-catching-and-recovering-mt_hEVa1JRrGu)

## Opens up

- [Debugging as a Method: Reproduce, Isolate, Fix](https://lightmysky.com/learn/computing/debugging-as-a-method-reproduce-isolate-fix-mt_2JGE4ICRf6)
- [Refactoring: Changing Structure Without Changing Behaviour](https://lightmysky.com/learn/computing/refactoring-changing-structure-without-changing-behaviour-mt_HHZufOyTg4)