I'm a fan of software tests that test the actual functionality of the software, not tests that are coupled to the implementation or the structure of the software. This is an interesting read.
In a nutshell, the best tests are the ones that you don't need rewriting/altering when you refactor code.
I read an analogy (yes, they're usually imperfect) a few days ago, and I've been thinking about it since.
It was on the site for Pact, and it said

"Do you set your house on fire to test your smoke alarm? No, you test the contract it holds with your ears by using the testing button."

At first, that seems like a good point.

But when you actually think about it, what does pressing the button actually test? It only really tests that when the button is pressed that a noise is made.

Pressing that button doesn't test

• That there is a smoke detector sensor in the equipment
• That the smoke detector sensor detects smoke
• That the smoke detector sensor is connected to the alarm
• That the smoke detector is situated in a good place to detect smoke

So in fact, the only really sure way to test that the alarm goes off when your house is on fire IS to set your house on fire and see if the alarm goes off.

Of course, in the real world, this is crazy. Houses are expensive and take a long time to create. Setting them on fire is dangerous. They're often connected to other houses.
But in the world of software, we can build a house, add a smoke detector to it, set it on fire, check the alarm goes off, and then clean up after ourselves in a fraction of a second. So why wouldn't we do it?

But despite the fact that pressing the button isn't the perfect test, you should still press the button to test your real-life smoke detectors.
Have you tested your smoke detectors recently? If not, go and do it now.