These smoke tests should not encompass your entire testing suite, rather they are a subset of tests that cover your top prioritized user flows. These are usually end-to-end tests that are executed in the build pipeline and are blocking, which means if any of them fail in a pull request, they will block the pull request from being merged. This blocking aspect of smoke testing is important because if the code you’re trying to push breaks a critical flow, you either need to update the test if the requirements have changed, or fix your code to ensure proper functionality of the feature.

Why Implement Smoke Testing?

Smoke tests should be put in place to ensure that your new code has not broken any existing functionality, and ideally they should be run in production. In software testing, you don’t want to be reactive — you don’t want to wait until a feature breaks, have a user report it to you, and then push a fix. You want to know if something is wrong before your users ever experience anything wrong. As a developer, smoke testing gives you that confidence you need to know you are releasing new features without breaking existing functionality.

Smoke Tests vs. Unit Tests

Both smoke tests and unit tests should be implemented in your build pipeline. Smoke tests should cover high-level end to end functionality, where unit tests should cover single component testing. Both should be present, and one should not replace the other.

Learn more about setting up your smoke tests here.