When you're writing tests for your code you often encounter some complex object that impedes your testing. Let's say some of you code uses a client library to talk to Twitter's API. You don't want your tests to have to talk to Twitter's servers: your tests would be slower, flakier, harder to setup, and require a working network connection.
The usual solution is to write a test double of some sort, an object that pretends to be the Twitter client but is easier to use in a test. Terminology varies slightly across programming communities, but you're probably going to make a fake, mock or stub Twitter client for use in your tests.
As you can tell from names like "fake" and "mock", there's a problem here: if you're tests are running against a fake object, how do you know they will actually work against the real thing?
You will often find the fake is insufficiently realistic, or just plain wrong, which means your tests using it were a waste of time.
I've personally had Python mock objects cause completely broken code to pass its tests, because the mock was a bit too much of a mockup.
There's a better kind of test double, though, known as a "verified fake". The key point about a verified fake is that, unlike regular fakes, you've actually proven it has the same behavior as the real thing. That means that when you use the verified fake for a Twitter client in a test you can trust that the fake will behave the same as real Twitter client. And that means you can trust your tests are not being misled by a broken fake.
Read more...