DCSIMG
Your UnitTests should have assertions. No, really. - Technicals and Technicalities

Technicals and Technicalities

Ariel's uneditable Bliki

Your UnitTests should have assertions. No, really.

I’m referring to the tests you wrote just to repro some exception. Most other tests (especially if you take a TDDish route) are meaningless without an expectation.

A regression test for an exception is a great safety net to have, and a good indication that your problem is gone, once it’s actually gone.

If you’re like me - you wrote your test without an assertion. It wasn’t really necessary at that point, since the test failed. A failing test is the first step on RedGreenRefactor, right?

It is, but that’s not the last step you need to take with that test.

After getting the test to pass you need to get back to it and add an assertion. Why? Because now this is not just a regression test – it’s a first class citizen in your unittest suite. This test represents a feature. Moreover – it represents an untested feature. We know this for a fact because it we would have had a test for this feature – we would have seen the aforementioned exception (the root for authoring this test).

Now, if this test tests a feature – there are some conditions for that feature’s correct behavior. Assert on them. Now you have a real test, which checks functionality, and not a specific implementation.

---

* Replace “feature” with “user story” or “requirement” wherever you fell.
* And when I say “Add an assertion” I mean just that – don’t go back and change the rest of the test because if you will – you would no longer have a test which “failed at least once”.

Comments

Dew Drop – August 21, 2009 | Alvin Ashcraft's Morning Dew said:

Pingback from  Dew Drop – August 21, 2009 | Alvin Ashcraft's Morning Dew

# August 21, 2009 3:24 PM

DotNetKicks.com said:

You've been kicked (a good thing) - Trackback from DotNetKicks.com

# August 21, 2009 4:57 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Enter the numbers above: