Problem:
For us, a smoke test is the first or second test that gets written as we start churning a module into good code. This allows us to proceed with at least a little more confidence that we can refactor. As larger and large refactorings become possible, each module ends up being fully tested, and the smoke tests a full unit test suite.
A SmokeTest is only a partial test, and frequently, it is difficult to debug. On the other hand, they are better than no tests, and a good way to provide files for full test suites to grow into.
-- JeffBay
Slightly variant use:
A SmokeTest is very close to an existence test, answering the questions: "Does this piece exist." and "Can it do anything at all." Common examples are "touch" of files or "ping" for IP connections.
While a SmokeTest has some use in developing new code, and working with code that runs together with other code, it's highly valuable in working with stuff that already exists, and working with independent chunks. Chunk examples are libraries, executables, subsystems, daemons, services, etc. Process examples are during integration, during deployment, and during any kind of modification to a system that in principle already works: upgrades, patches, rehosting, tool changes, and so on.
You make the change and execute a SmokeTest. Because the thing has worked before, and been exhaustively tested before (right?) if it works at all now, it is highly likely that everything works. Used this way, a SmokeTest really is looking for process errors - incorrect installation, or missing pieces of a deployment - vs. coding or logic errors. It's good to get them out of the way. It's a bit of overkill and a waste of time to fire up the debugger and walk through code to discover that your app isn't working because port 80 is blocked. Whether you should trust everything to work "the same" now that you've installed that new version of Oracle, or the latest OS patch from Microsoft is an engineering question. -- JamesBullock
The Smoke Test is MSF's main testing strategy. Every night all the unit tests are run, and results released the next day.
When working with hardware, the first test is "does it smoke when you turn it on". If it smokes, this is generally considered a BadThing. My dad tells a story of when he was still a smoker and designing hardware. A colleague had just finished wiring up an expensive and critically important new board. My dad lit a cigarette and snuck around behind the bench. When he heard the power switch, he blew a big lungfull of smoke up through the back of the board. Panic ensued, as you can well imagine. -- KentBeck
[Heh, heh -- every junior tech has pulled this one at one time or another during his career. I should know. -- MartySchrader]
After the SmokeTest, it's time for the TeaTest.
question: until now, i understood 'smoke tests' being AKA 'acceptance tests', but obviously this is wrong. every time a new load of our testobject is released, we run a set of basic usecases against it, and if these tests pass, we go on with more complex stuff.
Smoke Test:
The test carried out to prove the application does not work. - Vijay
Like a Sanity Check.
Smoke Test - to check/verify whether the build is ready to go for further testing phases. Smoke testing is conducted to ensure whether the most crucial functions of a program are working, but not bothering with finer details. Smoke testing is normal health check up to a build of an application before taking it to testing in depth
- Susanta Mohapatra.