--- title: "Unit Testing Denial Pattern #1: Pretending the test is no longer valid" url: "https://osherove.com/blog/2008/4/30/unit-testing-denial-pattern-1-pretending-the-test-is-no-long.md" canonical: "https://osherove.com/blog/2008/4/30/unit-testing-denial-pattern-1-pretending-the-test-is-no-long.html" published: "2008-04-30T13:21:26" updated: "2008-04-30T13:21:26" tags: ["Agile", "Agile Related", "Art Of Unit Testing", "Testing Guidelines"] author: "Roy Osherove" description: "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…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Unit Testing Denial Pattern \#1: Pretending the test is no longer valid By Roy Osherove April 30, 2008 In [Agile](https://osherove.com/blog/category/agile), [Agile Related](https://osherove.com/blog/category/agile-related), [Art Of Unit Testing](https://osherove.com/blog/category/art-of-unit-testing), [Testing Guidelines](https://osherove.com/blog/category/testing-guidelines) **Historical article** · Originally published April 30, 2008; technical details may be outdated. 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. ## Lessons on this topic - [Colors and Winners](https://courses.osherove.com/courses/tdd-pairing-sessions-building-a-go-game/colors-and-winners/) · TDD Pairing Sessions - Building a Go Game ## More in Agile [All posts in Agile](https://osherove.com/blog/category/agile) - May 15, 2008 ### [Typemock Isolator 4.2.4 is out](https://osherove.com/blog/2008/5/15/typemock-isolator-424-is-out.html) - May 10, 2008 ### [NullObject.For - As simple as it gets, but no simpler](https://osherove.com/blog/2008/5/10/nullobjectforlttgt-as-simple-as-it-gets-but-no-simpler.html) - Apr 25, 2008 ### [Pros and Cons and of using an Auto Mocking container in your tests](https://osherove.com/blog/2008/4/25/pros-and-cons-and-of-using-an-auto-mocking-container-in-your.html) - Apr 14, 2008 ### [Creating a AutoMockingContainer with Microsoft Unity - Pretty darn simple.](https://osherove.com/blog/2008/4/14/creating-a-automockingcontainer-with-microsoft-unity-pretty.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/