Alexandre Martins On Agile Software Development

11Aug/104

Deployment Smoke Tests: Is Anyone Being Slack?

I've always been a huge fan and advocate of using tests for developing applications. For me, working on a software without a decent suite of test is like walking on eggshells, each modification brings out the risk of breaking something on the system. To mitigate this risk I always make sure I have a minimum set of unit, integration and acceptance tests covering my application.

But does all that gives us the confidence that the system will work perfectly when it's deployed to any of the environments, on its way through the release pipeline? I thought so until work with this guy and read this book. Tom Czarniecki firstly introduced me the concept os smoke tests, then reading Jez Humble and David Farley's Continuous Delivery I could grok the real values of using it in conjunction with a build pipeline.

What are smoke tests?

As aforementioned, deployment smoke tests are quite handy because they give you the confidence that your application is actually running after being deployed. It uses automated scripts to launch the application and check that the main pages are coming up with the expected contents, and also check that any services your application depends on— like database, message bus, third-party systems, etc —are up and running. Alternatively you can reuse some acceptance or integration tests as smoke ones, given that they are testing critical parts of the system. The name smoke test is because it checks each of the components in isolation, and see if it emits smoke, as did with electronic circuits.

Provide clear failure diagnostics

If something goes wrong, then your smoke tests should give you some basic diagnostics explaining the reasons why your application is not working properly. In our current project at Globo.com, we are progressing towards start using Cucumber to write our smoke tests, thus having a set of meaningful and executable scripts, like this one below.

Feature: database configure
  System should connect to the database
  Scenario: should connect to the database
    When I connect to "my_app" database as root
    Then it should contain tables "users, products"

For those who like using Nagios for monitoring infrastructure, Lindsay Holmwood wrote a program called cucumber-nagios which allows you to write Cucumber tests that output the format expected of Nagios plugins, so that you can write BDD-style tests in cucumber and monitor the results in Nagios.

Knowing quickly whether you are ready or not!

Clearly rapid feedback and safety are the two major benefits of introducing smoke tests as part of a release process.

Rapid feedback

In our project, we implemented a deployment pipeline, so each new commit into the source repository is a potential deployable version to any environment, even to production. So we have the commit-stage where we run all the quick tests, and as soon as all of them passes, the acceptance-test-stage is automatically triggered, and the longer tests— integration and acceptance —are run, and once they've also passed, the application is automatically deployed into the dev environment. Getting a green at this stage means that it's successfully deployed and smoke tested. But there still some exploratory testing to be performed before releasing this version into the staging environment. And in our team, this is done by the product owner, together with a developer. So as soon as they are ready to sign the story off, all they have to do is click the manual button which in turn deploy the application into the qa1 (UAT) environment, and if it's green they can proceed, otherwise they pull the cord because something is malfunctioning, as you can see on the picture.

Don't let the application deceive you

It's quite frustrating, when all you need is the system to work as expected, because you are about to showcase it to your customers, and the first thing you click, all you see is a big and ugly error screen, instead of the page they were expecting. And later on you find out that it was due to database breakdown. What an embarrassing situation that could have been avoided by simply checking the smoke test diagnostics before showcasing.

Share and Enjoy:
  • Digg
  • del.icio.us
  • Reddit
  • Twitter
Comments (4) Trackbacks (0)
  1. Smoke tests are really valuable! You don’t want to start executing your 1k+ acceptance tests suite to discover after 30 minutes running 900 test cases that a simple search does not work. :)

  2. Good post Alex. Don’t forget the benefit of a status page showing your current configuration and the state of remote systems, like the database or some important web service, which can also be queried during a smoke test.

  3. @Guilherme Chapiewski I guess the tests you are talking about are more suitable for the commit-stage because its main purpose is find out quickly if the commit is good or not, before running the other longer tests. Deployment smoke tests’ purpose is more to check the environments you deployed your application, if the deployment was done successfully and if the components you rely on are actually up and running.

  4. @Tom Thanks Tom! I like the idea of the status page showing the current configuration. That’s another way of ensuring our configuration is correct. In my current project we’re now using Cucumber output to verify dependencies, instead of putting them on the status page. It’s been working nicely so far. Cheers!


Leave a comment

No trackbacks yet.