QA glossary
What is a test harness?
A test harness is the supporting code and setup that runs tests and reports their results. It starts the software under test, feeds it inputs, replaces parts the test should not depend on, and records what happened, so a test can run without a person driving it.
An example from QA practice
A payment service needs to be tested, but the real bank is not available to tests and charges real money. The team writes a harness: it starts the service, replaces the bank with a stub that answers "approved" or "declined" on demand, sends a set of payment requests and checks each response. The tests can now run in a build pipeline in seconds, and the declined case, which a real bank rarely produces, is tested every time.
What a harness usually contains
- A runner: the part that finds the tests, runs them and collects pass or fail.
- Stubs and mocks: stand-ins for services, databases or devices the test should not call for real.
- Test data: inputs and expected outputs, set up before each run and cleaned afterwards.
- Reporting: logs, screenshots and a result that a pipeline or a person can read.
A caution
A harness is software and can have bugs. A stub that always answers "approved" makes every test pass for the wrong reason, so the harness itself needs a check: break the code on purpose and confirm the tests go red.
How BetterQA does it
Flows is our browser test tool and it runs suites headless, so it can be the runner in a pipeline. Where a test needs a stand-in for an outside service, our engineers build the stubs as part of the suite and keep them in the same repository as the tests, so they are reviewed like any other code.
Related terms
What the structure around your tests does for you.