A test runner is a tool that finds automated tests, executes them and reports the results. It's usually run from the command line and can output results in formats that continuous integration systems understand.
Why it matters: The runner is what turns a folder of test code into a repeatable check. Its options decide which tests run, in what order, how failures are reported and how easily results fit into a team's pipeline and dashboards.
In practice: Teams install a runner as a development dependency, point it at their tests, and call it locally and in their CI pipeline. Most runners can filter tests, run them in parallel and export results in formats such as JUnit XML.
Examples:
- Running API tests with a JavaScript test runner such as Mocha as part of every build.
- Exporting test results in a format the CI server can parse and display.
Common pitfalls:
- Letting slow or flaky tests clog the runner until nobody waits for the results.
- Running different commands locally and in CI, so results don't match.
What's the difference between a test runner and a test framework? A test framework provides the structure and assertions for writing tests. A test runner executes them and reports results. Some tools do both.
