--- title: "Throw-Away Tests Vs. Tests that Last" url: "https://osherove.com/blog/2007/9/13/throw-away-tests-vs-tests-that-last.md" canonical: "https://osherove.com/blog/2007/9/13/throw-away-tests-vs-tests-that-last.html" published: "2007-09-13T16:01:23" updated: "2007-09-13T16:01:23" tags: ["Agile", "Agile Related", "Art Of Unit Testing", "Unit Testing"] author: "Roy Osherove" description: "TATs - That's what I call the tests people write when they are writing unit tests for the first time on a real project. Those tests usually don't last more that a few months before they either get deleted or ignored…" 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/" --- # Throw-Away Tests Vs. Tests that Last By Roy Osherove September 13, 2007 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), [Unit Testing](https://osherove.com/blog/category/unit-testing) **Historical article** · Originally published September 13, 2007; technical details may be outdated. TATs  - That's what I call the tests people write when they are writing unit tests for the first time on a real project. Those tests usually don't last more that a few months before they either get deleted or ignored completely because it takes too much time to maintain them, or no one understands what they are trying to test, or no one understands why they keep failing when the code seems fine, or all of the above combined. What's the difference between **TATs** and **TTLs** (Tests That Last)? **TTLs** are: - **Maintainable** \- Maintaining your production code when you have unit tests should not take much longer than maintaining it if you didn't have tests. for example - Assume a class that has 50 tests and suddenly you decide to change the constructor signature for that class. how long would it take you to make sure all the 50 tests for that class run again (or even compile)? - **Readable** \- Can you understand the test that somebody else wrote? Do you have to debug it to understand what it's testing? can you tell the intention just by looking at the test name? if it failed, will you know where the problem is? - **Trust-worthy** \- When you finish writing a feature, how comfortable do you feel just running all the tests and seeing them all pass? Does your test test the right thing? Do you have tests that keep failing but you think it's a normal behavior that they fail?  Do you have tests that seem to only pass if run in a specific order? Do you have tests that run other tests? Take any one of these away and the others crumble as quickly as I do when my wife asks me to take the garbage out. As a bonus I can tell you that you  what you have if even one of these is true is a **TAT**, not a **TTL**. Have **you** ever written **TATs**?  Were you able to make the move to **TTL**? If not, why? ## More in Agile [All posts in Agile](https://osherove.com/blog/category/agile) - Sep 18, 2007 ### [TDD Pattern: Composite Logic Development and Testing](https://osherove.com/blog/2007/9/18/tdd-pattern-composite-logic-development-and-testing.html) - Sep 16, 2007 ### [Mocks and Stubs - The difference is in the flow of information](https://osherove.com/blog/2007/9/16/mocks-and-stubs-the-difference-is-in-the-flow-of-information.html) - Sep 11, 2007 ### [Scrum is not enough. Try ScrumP](https://osherove.com/blog/2007/9/11/scrum-is-not-enough-try-scrump.html) - Sep 4, 2007 ### [Video: Agile Israel - Introduction to Agile, Scrum Planning](https://osherove.com/blog/2007/9/4/video-agile-israel-introduction-to-agile-scrum-planning.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/