Great question! This one really got me thinking, here it goes.
For your upcoming birthday, you ask your parents to buy you a Lego 1989 Batmobile.
The day finally arrives, and you are presented with a wrapped package, but they don't tell you what's inside. It is a surprise.
Your excitement rises, but before you get your hopes up - you examine the package.
Judging by the shape and size of the package, it matches the size of the 3306 piece box for the Lego 1989 Batmobile. Smoke test 1 passed.
You take the present in your hand and feel its weight. Its not too heavy, not too light. Just about right for a box of Legos. Smoke test 2, passed.
You decide to give it one final test before calling it. You shake the box and hear the familiar sound of Legos inside. Smoke test 3, passed!
Now you are fairly confident that the present is some kind of Lego, but you cannot really be sure if it is the Batmobile, so you start with user acceptance testing, unwrapping the present and validating the contents of the box.
Had any of the smoke tests failed, you would have immediately known that the present is not what you asked for, without investing time in detailed testing.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
During the development process, you have done all kind of extensive testing: unit testing, integration testing, user testing, whatever.
Before you start demo before the client though, you spend 5 minutes to test the most simple things to make sure still basic things still works because you would rather not be Bill Gates experiencing the Blue Screen Of Death:
Q: How much of the house is on fire?
A: I don't know, but I smell smoke, so there is definitely fire.
In other words, smoke tests give a quick check that things are ok or not. Smoke tests pass then hey, probably no fires. Smoke tests fail, there is a fire. They are used with other types of tests to give a more complete picture.
In plumbing, a smoke test forces smoke through pipes in order to find leaks. If you see smoke somewhere it shouldn't be, you've found a leak. Or if smoke does not appear at the other end of the pipe, you've got a blockage. In software, a smoke test usually will pass test data through a process from end to end and verify that the results of the process match expectations. This would be an integration test "in situ", rather unit testing of individual components in a process.
Max is a startup software engineer. He seeks to use what he has learnt as a startup founder and tech community leader to solves hard problems with innovate products or services.
Smoke test is like when you see me and you yell monster!!! when we are playing a game. So you're doing it on a computer and it yells monster when it found something bad.
Great question! This one really got me thinking, here it goes.
For your upcoming birthday, you ask your parents to buy you a Lego 1989 Batmobile.
The day finally arrives, and you are presented with a wrapped package, but they don't tell you what's inside. It is a surprise.
Your excitement rises, but before you get your hopes up - you examine the package.
Judging by the shape and size of the package, it matches the size of the 3306 piece box for the Lego 1989 Batmobile. Smoke test 1 passed.
You take the present in your hand and feel its weight. Its not too heavy, not too light. Just about right for a box of Legos. Smoke test 2, passed.
You decide to give it one final test before calling it. You shake the box and hear the familiar sound of Legos inside. Smoke test 3, passed!
Now you are fairly confident that the present is some kind of Lego, but you cannot really be sure if it is the Batmobile, so you start with user acceptance testing, unwrapping the present and validating the contents of the box.
Had any of the smoke tests failed, you would have immediately known that the present is not what you asked for, without investing time in detailed testing.
This is brilliant, truly a great ELI5 answer. Thank you!
Way to go! You deserve Lego 1989 Batmobile for this amazingly detailed explanation. :)
Wow. This deserves a prize 🔥🔥🔥🔥
Awesome explaination
Awesome, give this man all the medals !
Wow!
During the development process, you have done all kind of extensive testing: unit testing, integration testing, user testing, whatever.
Before you start demo before the client though, you spend 5 minutes to test the most simple things to make sure still basic things still works because you would rather not be Bill Gates experiencing the Blue Screen Of Death:
Q: How much of the house is on fire?
A: I don't know, but I smell smoke, so there is definitely fire.
In other words, smoke tests give a quick check that things are ok or not. Smoke tests pass then hey, probably no fires. Smoke tests fail, there is a fire. They are used with other types of tests to give a more complete picture.
In plumbing, a smoke test forces smoke through pipes in order to find leaks. If you see smoke somewhere it shouldn't be, you've found a leak. Or if smoke does not appear at the other end of the pipe, you've got a blockage. In software, a smoke test usually will pass test data through a process from end to end and verify that the results of the process match expectations. This would be an integration test "in situ", rather unit testing of individual components in a process.
Interesting analogy. Makes the concept clear
Similar to Smoke and Mirrors it's not the real thing. An illusion of safety. Want to release to production? Run a smoke test.
Smoke test is like when you see me and you yell monster!!! when we are playing a game. So you're doing it on a computer and it yells monster when it found something bad.
Smoke test is basically a sanity check to make sure the product won't explode if you push an update.