Unit Testing DOES work

And isn't it satisfying to see those green checkmarks..?

Unit testing is one of those ideas that sounds deeply sensible, like eating vegetables or stretching before exercise—and yet is mysteriously skipped when things get “busy.” This is a shame, because unit tests are one of the simplest ways to reduce bugs, preserve sanity, and avoid late-night debugging sessions that end with questioning your life choices.

The good news? Writing tests is no longer a heroic act. With modern tooling and AI assistance, most of the work is mechanical. Which means skipping tests today is a bit like refusing to use spellcheck out of principle.

Why Unit Testing Is Worth the Mild Inconvenience

1. Bugs Hate the Spotlight

Unit tests shine a harsh little flashlight on individual pieces of logic. When something breaks, you don’t get a vague “the app is weird” report—you get a failing test pointing directly at the offender.

2. Refactoring Without Fear

Changing code without tests is like rearranging furniture blindfolded. With tests, you can confidently improve structure, performance, or readability knowing that if something snaps, you’ll hear about it immediately.

3. Tests as Living Documentation

Tests quietly explain:

  • What this code is supposed to do
  • Which inputs are valid
  • Which edge cases actually matter

They’re often more honest than comments, which have a habit of lying once nobody is watching.

AI Has Made Testing Boring (in a Good Way)

Many historical objections to unit testing have quietly expired:

  • “It takes too long”
  • “There’s too much boilerplate”
  • “I don’t know what to test”

AI tools can now generate:

  • Test skeletons
  • Common edge cases
  • Mocks and stubs
  • Entire test files from existing code

You still need judgment—but you no longer need to start from a blank screen and a mild sense of dread.

Keep Tests Close, Like Houseplants

Tests belong next to the code they test.

Why?

  • You see them when editing the code
  • You’re reminded to update tests when behavior changes
  • It’s immediately obvious what is and is not covered

This beats spelunking through a distant tests/ directory like an archaeologist searching for meaning.

Example Folder Structure

src/
  common/
    Button/
      Button.tsx
      Button.test.tsx
    Card/
      Card.tsx
      Card.test.tsx
  data/
    users.ts
    users.test.ts

Simple, local, and pleasantly boring.

Small Files Are a Feature, Not a Limitation

Here’s a quiet truth: code that is easy to test is usually well designed.

If a file, class, or component is:

  • Small
  • Single-purpose
  • Light on dependencies

…it will almost test itself.

The 500-Line Rule of Raised Eyebrows

A file creeping past ~500 lines is a red flag. Not an automatic failure—but definitely a raised eyebrow.

Common symptoms include:

  • Multiple responsibilities hiding in plain sight
  • Conditional logic soup
  • “Helper” functions that are anything but helpful

Large files are hard to understand, hard to reason about, and hard to test. Breaking them apart almost always improves both testability and readability.

If testing feels painful, it’s often your code gently asking to be split up.

What Makes a Good Unit Test

A good unit test is:

  • Focused – tests one thing
  • Fast – no real networks, databases, or dramatic pauses
  • Deterministic – same result every time
  • Readable – understandable in under 10 seconds

If a test requires a deep breath before reading, it’s doing too much.

Arrange / Act / Assert

Most tests benefit from this simple rhythm:

  1. Arrange – set up inputs and mocks
  2. Act – run the code
  3. Assert – verify the outcome

Predictable structure makes failures easier to diagnose and fixes quicker to apply.

What Not to Test (Please Don’t)

Unit tests are not for:

  • CSS minutiae
  • Third-party internals
  • Exact implementation details

Test behavior, not how clever you were that day.

If you rewrite code and every test explodes—but behavior didn’t change—the tests were too intimate.

When Testing Feels Awful

This is usually a design smell, not a tooling problem.

Common causes:

  • Functions doing too many things
  • Hidden side effects
  • Excessive dependencies
  • Classes that secretly want to be three classes

Unit tests have a way of exposing these issues politely but firmly.

A Sensible Rule of Thumb

  • Test logic you don’t want to debug twice
  • Add tests when fixing bugs (so they stay fixed)
  • Aim for meaningful coverage, not perfect coverage

Green checkmarks are nice. Maintainable code is nicer.

Final Thought

Unit tests aren’t about dogma or purity. They’re about:

  • Smaller files
  • Clearer responsibilities
  • Fewer surprises
  • Less cognitive load

With AI handling the repetitive bits, unit testing is mostly a design decision now—not a time sink.

Keep things small. Keep them focused. Your future self will quietly thank you.

Back to Philosophy