--- title: "When should you remove or change a unit test?" url: "https://osherove.com/blog/2005/4/3/when-should-you-remove-or-change-a-unit-test.md" canonical: "https://osherove.com/blog/2005/4/3/when-should-you-remove-or-change-a-unit-test.html" published: "2005-04-03T09:55:00" updated: "2005-04-03T09:55:00" tags: ["Agile Related", "Testing Guidelines"] author: "Roy Osherove" description: "As a rule, a passing test should never be removed. That's because passing tests serve as the regression tests for our maintenance work. They are there to make sure that when we change code we don t break anything else…" 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/" --- # When should you remove or change a unit test? By Roy Osherove April 3, 2005 In [Agile Related](https://osherove.com/blog/category/agile-related), [Testing Guidelines](https://osherove.com/blog/category/testing-guidelines) **Historical article** · Originally published April 3, 2005; technical details may be outdated. As a rule, a passing test should **never** be removed. That's because passing tests serve as the regression tests for our maintenance work. They are there to make sure that when we change code we don t break anything else that s already working. Anywhere. That's also why you don't want to **change** a passing test unless the change is just to make it more readable. But sometimes we might get some failing tests even though the change was absolutely reasonable. That usually means we ve encountered conflicting requirements. How does that happen? Here s how it might sound: A year ago company X needed a feature of their calculator to be able to parse any amount of numbers, as long as they are positive. A number of tests were written to satisfy this requirement. Here s one: \[ExpectedException(typeof(Exception), Negatives not allowed )\] Void Sum\_Negative1stNumberThrowsExcpeiton() {      Sum( -1,1,2 ); } Today, the VP decided that a new feature is required to have negative numbers allowed in the calculator. A developer not knowing about the previous requirement builds a test case such as this and makes it pass: Void Sum\_Negative1stNumberCalculatesCorrectly() {      Int sumResult = Sum( -1,1,2 );      Assert.AreEqual(2,sumResult); } Alas, the earlier test fails. It broke due to a requirement change. Now s the time for that developer to realize that an older requirement has changed. That test is indeed no longer valid and served no real purpose. It was written for a requirement that is no longer valid. There are two possible routed to go here: \-         Delete the failing test after verifying that it is longer valid \-         Change the old test o       Either to test the new requirement o       **Or to test the older requirement under new settings** The highlighted line above indicates that this is an important case. Sometimes a test is still valid even if it uses non-valid ways to accomplish its task. A good example would be to have a Person class with a constructor that takes one parameter. A test that creates this class to test some functionality of it is using this constructor. Years later another requirement comes along and another parameter is added to the constructor of the class. Suddenly the old test breaks, even though it has nothing to do with the constructor other than it needs to create the class in order to test its functionality. Removing the test then becomes a bad thing because you lose testing of some important functionality. In that case you might  want to change the creation of the class in your old test so that you can keep using it for the purpose it was built for. Assuming you have 200 failing tests just because they use that old constructor you might be in for a problem maintaining your tests. That s why you should always remove duplication in your tests just as you would in production code. ## More in Agile Related [All posts in Agile Related](https://osherove.com/blog/category/agile-related) - Apr 3, 2005 ### [How Do You Explain Pair Programming?](https://osherove.com/blog/2005/4/3/how-do-you-explain-pair-programming.html) - Apr 3, 2005 ### [Migrating Nunit 1.0 to 2.2.2 - step by step walkthrough](https://osherove.com/blog/2005/4/3/migrating-nunit-10-to-222-step-by-step-walkthrough.html) - Apr 3, 2005 ### [Test Coverage and testing angles](https://osherove.com/blog/2005/4/3/test-coverage-and-testing-angles.html) - Apr 3, 2005 ### [A Unit test should test only one thing](https://osherove.com/blog/2005/4/3/a-unit-test-should-test-only-one-thing.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/