Looking at tests in a different light.
In looking at how tests help eliminate bugs, I realized that one way it does so is by automatically notifying you when something doesn’t work in the way the test specifies it “should”. This got me thinking about tests from a different perspective…as an auto-notification process.
In looking at tests this way, I find myself asking a very different question: “What do I want to be notified of?”
The “normal” way of thinking about tests will lead us to answers like: “When feature X doesn’t work” or “When scenario Y doesn’t produce output Z.” But these are narrowly focused questions. Is that all we could possibly want to know about our code or the system under test?
What other conditions would a notification (failed test) be useful for?
Maybe we have an expected failure when the volume of data exceeds a certain number of rows. We know we need to make certain changes to the system when this happens. A test could “remind” us of that automatically when that happens.
We could have performance monitored by writing a test that will notify us if it takes more than X number of seconds to perfom operation Z. Thus we know we need to peform some optimzation.
Looking at tests in this light opens up the possibility thinking “outside the box” concerning testing.
Some of the uses that stem from answers to the question “What do I want to be notified of?” may be better suited for other tools than your standard xUnit suite, while others may not. Its just something for your brain to chew on.
I’m interested to see what others think of this, and the different ways it could be used.
-=CE=-
