Smoke Tests

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!

Published 20 Feb 2019

<%= @today.i_learned %> An early-career Web Developer's discoveries in Ruby, Rails, Javascript, and React. Currently the Support Engineer @ Pingboard in Austin, TX. I just write what I learn and try not to overthink things.
Kelsey Huse on Twitter