# Why the Author Is Skeptical of Test-Driven Development

DevFeed: [Why the Author Is Skeptical of Test-Driven Development](<https://devfeed.tech/articles/the-cults-of-tdd-and-genai-20793.md>)

Original publisher: [Read original article](<https://drewdevault.com/blog/Cult-of-TDD-and-LLMs/>)

Author: January

Published: 2026-01-29T00:00:00Z

Content type: opinion

Language: en

Sources: [Drew DeVault](<https://devfeed.tech/sources/drew-devault.md>)

Topics: [Test-driven development](<https://devfeed.tech/topics/tdd.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [test-coverage](<https://devfeed.tech/topics/test-coverage.md>)

Tags: [software-testing](<https://devfeed.tech/tags/software-testing.md>), [tdd](<https://devfeed.tech/tags/tdd.md>), [test-coverage](<https://devfeed.tech/tags/test-coverage.md>), [testing](<https://devfeed.tech/tags/testing.md>), [tests](<https://devfeed.tech/tags/tests.md>), [unit-test](<https://devfeed.tech/tags/unit-test.md>)

## AI overview

The author argues that test-driven development can provide useful rapid feedback and test coverage, but warns that it may shape code around testability and cannot ensure that tested behavior matches actual software requirements.

## Source excerpt

I've gotten a lot of flack throughout my career over my disdain towards test-driven development (TDD). I have met a lot of people who swear by it! And, I have also met a lot of people who insisted that I adopt it, too, often with the implied threat of appealing to my boss if appealing to me didn't work. The basic premise of TDD, for those unaware, is that one first writes a unit test that verifies the expected behavior for some code they want to write, observes the new test fail, and then one writes the implementation, iterating on it until the test passes. The advantage of this approach is, first, to ensure that your codebase is adequately covered by testing, and, second, to provide you a rapid feedback loop to assist in your work. I have often found elements of TDD to be quite useful. Using a unit test or something similar to provide an efficient rapid feedback loop is a technique which I have employed many times. However, I am and have always been skeptical of the cult which arises around automated software testing and in particular TDD. A lot of people adopt an unquestioning loyalty to TDD, building tools and practices and vibes around the idea. It's often too much. The flaw with TDD is that, while it ensures that you have a test for every function you write, it also exerts an influence on the tested codebase, shaping the code to be as "testable" as possible, which only sometimes leads to better code. Moreover, TDD has no means of ensuring that the behavior that your tests verify is the right behavior for your software to have. Software with a thousand passing tests and 100% test coverage could be doing whatever the user or the business or whatever needs it to, but it could just as easily not meet the requirements in spite of those comprehensive tests - and in any case it gives you confidence in your work, which may or may not be misplaced. The cult of TDD exploits the fact that TDD is very good at making you feel like a good, diligent programmer. That rapid fee