I wrote down
Smoke Tester as something to research on my first day of work. Previously, I had worked on personal projects and doing contract work for start-ups and none of the code bases had tests. Testing is an area I’ve been wanting to improve in and gain knowledge about, since I recognize that it helps to add features with less risk, ultimately making development faster and the number of bugs in software fewer.
I learned that a Smoke Test is a test ran on an app pre-deployment, in order to verify that the main function of the app is still working with the new code included.
When I have written my own tests for personal projects (which has been rare), I will run the tests locally, push the code, run the build process, and deploy. If there is a descrepancy between my local app and the app built on the server, I wouldn’t notice it until it’s deployed live. Smoke tests add an extra layer of automated testing after the app is built on the server.
Smoke Tests are part of a larger topic - Continuous Integration. At Pingboard we use CircleCI for continuous integration which gives us safety and confidence in our deploys. It’s configured to run our Unit/System tests whenever a new deploy is requested for our staging environment, or for a review app. A review app is a temporary app used to isolate usually one PR, and is deleted once QA is done. It’s possible to configure a Slack bot to notify a specific channel whenever Smoke Tests fail. Additionally, if CircleCI is integrated into a Github repo and the smoke tests fail, the PR will show that CircleCI failed the check. ❌
If you would like to read more, this is a great article about Smoke Testing by Functionize, which I found helpful for my own research!