# Weighing in on Long Live Testing

DevFeed: [Weighing in on Long Live Testing](<https://devfeed.tech/articles/weighing-in-on-long-live-testing-31905.md>)

Original publisher: [Read original article](<http://blog.jayfields.com/2014/05/weighing-in-on-long-live-testing.html>)

Author: Jay (noreply@blogger.com)

Published: 2014-05-19T16:52:00Z

Content type: opinion

Language: en

Sources: [Jay Fields](<https://devfeed.tech/sources/jay-fields.md>)

Topics: [Testing](<https://devfeed.tech/topics/testing.md>), [Test-driven development](<https://devfeed.tech/topics/tdd.md>), [unit tests](<https://devfeed.tech/topics/unit-tests.md>), [Refactoring](<https://devfeed.tech/topics/refactoring.md>), [pair\_programming](<https://devfeed.tech/topics/pair-programming.md>)

Tags: [behavior](<https://devfeed.tech/tags/behavior.md>), [code-coverage](<https://devfeed.tech/tags/code-coverage.md>), [java](<https://devfeed.tech/tags/java.md>), [pair-programming](<https://devfeed.tech/tags/pair-programming.md>), [refactoring](<https://devfeed.tech/tags/refactoring.md>), [tdd](<https://devfeed.tech/tags/tdd.md>), [testing](<https://devfeed.tech/tags/testing.md>), [unit-testing](<https://devfeed.tech/tags/unit-testing.md>), [unit-tests](<https://devfeed.tech/tags/unit-tests.md>)

## AI overview

The author argues that test-driven development and testing practices should be chosen based on their purpose and context rather than followed dogmatically. Drawing on experience with a simple internal application, the article emphasizes asking why a test is being written and identifies goals such as validation, regression prevention, coverage, legacy-code refactoring, and documenting system behavior.

## Source excerpt

DHH recently wrote a provocative piece that gave some views into how he does and doesn't test these days. While I don't think I agree with him completely, I applaud his willingness to speak out against TDD dogma. I've written publicly about not buying the pair-programming dogma, but I hadn't previously been brave enough to admit that I no longer TDD the vast majority of the time. The truth is, I haven't been dogmatic about TDD in quite some time. Over 6 years ago I was on a ThoughtWorks project where I couldn't think of a single good reason to TDD the code I was working on. To be honest, there weren't really any reasons that motivated me to write tests at all. We were working on a fairly simple, internal application. They wanted software as fast as they could possibly get it, and didn't care if it crashed fairly often. We kept everything simple, manually tested new features through the UI, and kept our customer's very happy. There were plenty of reasons that we could have written tests. Reasons that I expect people will want to yell at me right now. To me, that's actually the interesting, and missing part, of the latest debate on TDD. I don't see people asking: Why are we writing this test? Is TDD good or bad? That depends; TDD is just a tool, and often the individual is the determining factor when it comes to how effective a tool is. If we start asking "Why?", it's possible to see how TDD could be good for some people, and bad for DHH. I've been quietly writing a book on Working Effectively with Unit Tests, and I'll have to admit that it was really, really hard not to jump into the conversation with some of the content I've recently written. Specifically, I think this paragraph from the Preface could go a long way to helping people understand an opposing argument. Why Test? The answer was easy for me: Refactoring told me to. Unfortunately, doing something strictly because someone or something told you to is possibly the worst approach you could take. The more time