Smoke Test vs Integration Test: What Each Checks

A smoke test checks that the build works at all: it runs, the interface opens, the main action does something. An integration test checks that separately built parts work once they are connected to each other. One is a quick gate before deeper testing. The other goes deep on the seams between parts. Most teams need both. For how integration tests relate to unit tests, see unit tests vs integration tests. This post covers what each one checks, when each runs, and how they look for an API.

Smoke test vs integration test at a glance

A smoke test asks “is this build so broken that testing it further is pointless?” An integration test asks “do these parts work together?”

	Smoke test	Integration test
Question	Do the main functions appear to work?	Do separately built parts work when connected?
Scope	The whole system together	Several components, modules or services together
Depth	Not a full test of the system	Interactions and data exchange between the parts
Runs	Right after a build or a deployment	Once the parts are connected
A failure means	The build may be too broken to test further	The parts do not work together as expected

A smoke test is better at speed and breadth: it frequently runs quickly and covers the whole system together. An integration test is better at depth: it finds faults in the seams a smoke test never reaches.

What a smoke test checks

A smoke test is a subset of test cases that covers the most important functionality of a system, as the Wikipedia article on smoke testing puts it. Its job is to help assess whether the main functions appear to work correctly. Atlassian describes smoke tests as basic tests meant to be quick to execute, with the goal of giving you assurance that the major features of your system work as expected.

The questions are blunt. A smoke test may ask whether the program runs, whether the user interface opens, or whether clicking the main button does anything. The aim is to find out whether the application is so badly broken that further immediate testing is unnecessary.

Smoke tests are deliberately thin. They test the whole system together and are not meant to cover everything. That is their limit as well as their strength: a passing smoke test says the build is worth testing, not that it is correct.

Smoke tests are defined by their purpose, not by a test technique. They can be functional tests or unit tests. For how the other kinds of API test are told apart, see types of API testing.

What an integration test checks

An integration test determines whether independently developed units of software work correctly when they are connected to each other. The focus is the interactions and the data exchange between the integrated parts, not the parts in isolation.

That is what a smoke test cannot see. A smoke test can pass while the data behind the main pages is wrong. An integration test follows the data across the seam and checks what came out the other side. For a worked API example, see what integration testing is, or integration testing examples for a REST API.

Integration tests also have a place next to unit tests, not in place of them. In one experiment we ran 2,189 unit tests and one API flow test against 8 ordinary bugs. The unit tests caught 5 and the flow caught 6, and each caught something the other missed.

When each one runs

A smoke test runs at the edges of a change. It is useful right after a new build is made, to decide whether to run more expensive tests, and right after a deployment, to confirm the application is running in the new environment.

A failed smoke test is a stop sign. If one fails, there is a serious problem with the site’s functionality, and the new changes should not be deployed until the failures are fixed, as one explainer puts it. Smoke tests frequently run quickly, so results arrive sooner.

An integration test runs once the parts exist and are connected, so run it on every pull request too. The two are not rivals on a pull request. The smoke check answers “is it alive?” first, and the integration tests answer “do the parts still work together?” after it. Skipping the first wastes time on a dead build. Skipping the second lets a live build ship with broken wiring.

Smoke and integration checks for an API

For an API, a smoke check is a short flow against the running app, such as sign in and read one resource. An integration check is a longer flow that sends real requests through the routes, auth and database and reads the answers back.

Stresseur records how an API is really used during development, turns those flows into YAML tests and runs them in CI on every pull request. The flows live in the repo under api-tests/. npx stresseur init-ci writes the GitHub Actions workflow. Generated flows check each answer as well as the status. After a create, a later read must hold the new id, or a value the user typed.

Treat a short recorded flow as your smoke check and the full set as your integration check, and read each result at the step that failed. For the CI setup, see run API tests on every pull request. In CI each flow runs 13 times, one warm-up and 12 measured, and per-step timings are uploaded. To see how this works, read API integration tests from real traffic.

Conclusion

A smoke test and an integration test answer different questions. The smoke test asks whether the build is alive, and it should be fast and shallow. The integration test asks whether the connected parts work together, and it should go deep. Run the smoke check first and the integration tests after it, and let a failed smoke test stop the pipeline before you spend time on the rest.