Smoke testing is something less commonly embraced by teams that write automated tests. Writing tests to verify things are working, or to expose bugs, is a commonly adopted practice, and many teams pick up the idea of acceptance testing to verify whether their applications are meeting customer demands.

But smoke testing is a little different. One of the key ideas with smoke testing is to see if the system has a pulse. What does this mean? It's similar to when a doctor first sees a patient. The first thing they do is check the patient's pulse along with other vital signs. No pulse; critical issue! So what exactly, in software, constitutes a pulse? That is what we'll explore in the recipes in this chapter.

Instead of thinking about comprehensive test suites that make sure every corner of the system has been checked, smoke testing takes a much broader perspective. A set of smoke tests is meant to make sure the system is up and alive. It's almost like a ping check. Compare it with sanity tests. Sanity tests are used to prove a small set of situations actually work. Smoke testing, which is similar in the sense that it is quick and shallow, is meant to see if the system is in an adequate state to proceed with more extensive testing.

If you imagine an application built to ingest invoices, a set of smoke tests could include:

Does this sound like a small set of tests? Is it incomplete? Yes it is. And that's the idea. Instead of verifying our software parsed everything correctly, we are verifying just a few key areas that MUST be working. If it fails to read one file, then there is a major issue that needs to be addressed. If the grand total of the bill is incorrect, again, something big must be taken care of.

Smoke tests are also good to use when preparing for a customer demo. With the tension turned up, it's good to run tests more often to make sure we haven't broken anything. Before launching a demo, one last pulse check to know the system is alive may be needed.

This chapter also dives into load testing. Load testing is crucial to verify whether our applications can handle the strain of real-world situations. This often involves collecting real-world data and playing it back through our software for a reproducible environment. While we need to know our system can handle today's load, how likely is it that tomorrow's load will be the same? Not much.

It is very useful to seek out the next bottleneck in our application. That way, we can work towards eliminating it before we hit that load in production. One way to stress the system is to play back real-world data as fast as possible.

In this chapter, we will look at some recipes involving both smoke testing and load testing the network management application we developed in the previous chapter with the recipe from Chapter 7, Building a network management application. The types of loads we will be placing on the application could also be described as soak testing and stress testing. Soak testing is described as putting a significant load on the system over a significant period of time. Stress testing is described as loading down a system until it breaks.

The code in this chapter also uses several utilities provided by Spring Python (http://springpython.webfactional.com). You can read more details about its use and functionality, as well as how to install it, in Chapter 7.

Many of the recipes in this chapter interact with a MySQL database. Install the Python MySQLdb library by typing: pip install mysql-python.

Several of the recipes in this chapter use Python Remote Objects or Pyro (http://www.xs4all.nl/~irmen/pyro3/). It is a Remote Procedure Call (RPC) library that supports communicating between threads and processes. Install Pyro by typing: pip install pyro.