Unit Testing, Agile Development, Leadership & .NET - By Roy Osherove
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.
Could another reason you experienced this be that you had an obscure test? See xunitpatterns.com/Obscure%20Test.html.
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.
Roy just posted a unit testing anti-pattern based on his personal experience. I'd like to follow up with
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 :)