Unit Testing Denial Pattern #1: Pretending the test is no longer valid - ISerializable - Roy Osherove's Blog

Unit Testing Denial Pattern #1: Pretending the test is no longer valid

Today was both a good day for e and a bad day for me. Good day because I managed to get a full suite of tests that were somehow failing to work again after a refactoring that got out of hand. Bad - because out of all the tests, one of them failed.

Here's the part I'm ashamed of:

I was working with a pair, and when we both looked at the failing test, I went out and said "Oh, I think this test is no longer valid. It may just need to be removed". We both knew it was still a valid test, that for some reason was failing. But I was on such a role with making everything work, that test was feeling like a thorn in my thumb that I wanted to get rid of.

It was a hard few minutes to convince ourselves to debug through the test and realize what the problem may be

So, denial pattern #1:

Forces: You just want to get on with your code, with only one or two tests that are "ruining the party"

Behavior:

Instead of fixing them debugging them or accepting that you might not have fixed everything, you try to tell yourself that the tests may no longer be valid without actually checking your assumption, which you really wish would be true.

How to avoid: work in pairs. It's harder to ignore a problem (or at least more awkward) with 4 eyes staring at it.

Published Wednesday, April 30, 2008 4:21 PM by RoyOsherove
Filed under: , , ,

Comments

Wednesday, April 30, 2008 5:23 PM by Jeremy D. Miller

# re: Unit Testing Denial Pattern #1: Pretending the test is no longer valid

Anti-pattern #2:  The unit test is written so poorly that you have no idea if it's important anymore or not.

Solution:  Get in the wayback machine and whack yourself upside the head as you write that unit test in the first place.

Wednesday, April 30, 2008 8:03 PM by Michael Hedgpeth

# re: Unit Testing Denial Pattern #1: Pretending the test is no longer valid

Could another reason you experienced this be that you had an obscure test?  See xunitpatterns.com/Obscure%20Test.html.

Wednesday, April 30, 2008 8:13 PM by RoyOsherove

# re: Unit Testing Denial Pattern #1: Pretending the test is no longer valid

An obscure test would have made it easy to disclaim as "invalid", but this test was so simple and understandable, it was an outright self-lie that I wanted to be believe it to be invalid.

Had it not been readable, the path taken could have been different - for the worse.

So, one other solution: make sure your test is *not* obscure so that the truth hits you in the face when you see it - the test is indeed valid.

Thursday, May 01, 2008 6:26 AM by ploeh blog

# Unit Testing Anti-Pattern #2: Not Covering Bugs In Your Tests With Tests

Roy just posted a unit testing anti-pattern based on his personal experience. I'd like to follow up with

Thursday, May 01, 2008 7:24 AM by Travis Laborde

# re: Unit Testing Denial Pattern #1: Pretending the test is no longer valid

Brian Donahue (http://www.persistall.com/) gave a talk last night at the PhillyNJ.NET user group (http://www.phillynj.net) about BDD and one thing that really clicked for me was the naming conventions in the tests.

Where I've had tests named like "TestCustomerFactoryReturnsACustomer" I see the effectiveness now of using a better naming convention which more closely relates to the actual business need being verified.

If I'm explaining it correctly I think I'll be ending up now with classes named like "When_Valid_Customer_Is_Requested" which might have test methods like "Should_return_Customer_Instance" and perhaps "Should_Update_Audit_Log" etc.

Given that sort of naming convention I think it will be much easier in the future to tell if a test is still valid given any new context.

Probably you already know all this, but reading your post the morning after having that talk from Brian made me just HAVE to comment :)