Testing & Quality

A statement inside a test that says 'I expect this to be true.' If the expectation is wrong, the test fails and tells you exactly what didn't match. Assertions are how a test actually checks that the code is doing what it's supposed to.

A test that drives the whole app from the outside, just like a real person would: clicking buttons, filling out forms, going from one page to the next. It's the most realistic kind of test (it catches problems no other test would), but also the slowest and the most easily upset by little changes.

A pre-prepared piece of fake data that tests can rely on: like a sample user, a stock list of products, or a saved response. Using the same fixture across many tests keeps them tidy and consistent, instead of every test inventing its own slightly different sample.

A test that sometimes passes and sometimes fails for no clear reason: usually because it depends on something it shouldn't, like the time of day, the order other tests ran in, or how fast the network is responding. Flaky tests slowly destroy the team's trust in the whole test suite.

A test that checks whether several pieces of an app work correctly when they're put together: talking to a real database, hitting a real internal service, the way they would in real life. It catches the kinds of bugs that only show up when separate pieces have to cooperate.

Automatic proofreading for code. A linter scans through the source files and flags stylistic mistakes, suspicious patterns, and likely bugs: without actually running the code. It catches the small problems early, before they reach reviewers or tests.

A pretend version of something the code normally talks to, a database, an email service, a payment processor, used during tests. The mock behaves the way the test wants and quietly records what the code asked it to do, so the test can check that the right things happened.

A test added the moment a bug is fixed, so the same bug can never quietly sneak back into the app later. It's a permanent reminder pinned to that exact failure: 'this once broke; here's the test that proves it can't break the same way again.'

A test that takes a 'photo' of what something looks like the first time it runs and saves it. From then on, every test run compares the current look against the saved photo and warns you if anything has changed. Easy to set up, but you have to actually look when something is different: not just rubber-stamp the new photo.

Two test helpers, often confused. A stub replaces a real function with a fake one that always returns whatever the test wants: used to control what the code sees. A spy doesn't change anything; it lets the real function run and just quietly takes notes about how it was called: used to check that the right calls happened.

A backwards-feeling habit: write the test first, then write just enough code to make the test pass, then clean up. The discipline forces you to think about how your code should behave before you start writing it, which often produces simpler designs and fewer surprises later.

A measurement of how much of an app's code is actually exercised by its tests. High coverage doesn't prove the code is correct, but very low coverage is a warning sign. It means big stretches of the app could be quietly broken without anyone finding out.

A bunch of related tests grouped together: usually all the tests for one feature or one piece of the app. Grouping them lets the team run just one suite (when they're working on that one area) or run them all at once before a release.

A small, fast test that checks one tiny piece of an app on its own, a single calculation, one rule, one function, without any of the surrounding parts. Unit tests are quick to run and form the bulk of most teams' testing because they catch problems instantly.