---
title: "Comment by Ákos Kőműves on \"Why I Don't do TDD\" | Hashnode"
description: "Writing lots of tests. How can that be bad? TDD is good only if you're testing the right thing. While good coverage/documentation, as you said, is just good"
url: "https://hashnode.com/posts/why-i-dont-do-tdd/6373af8a4a2eb420e8853ec0/comment/637632d9559c02733a0ad8d7"
---

[Discussion](https://hashnode.com/posts/why-i-dont-do-tdd/6373af8a4a2eb420e8853ec0)

Comment [Why I Don't do TDD](https://hashnode.com/posts/why-i-dont-do-tdd/6373af8a4a2eb420e8853ec0)

[Ákos Kőműves](https://hashnode.com/@akoskm)

[Nov 17, 2022](https://hashnode.com/posts/why-i-dont-do-tdd/6373af8a4a2eb420e8853ec0/comment/637632d9559c02733a0ad8d7)

> Writing lots of tests. How can that be bad?

TDD is good only if you're testing the right thing.

While good coverage/documentation, as you said, is just good programming.

[Julian Ewers-Peters](https://hashnode.com/@ewerspej)

[Nov 17, 2022](https://hashnode.com/posts/why-i-dont-do-tdd/6373af8a4a2eb420e8853ec0/comment/637632d9559c02733a0ad8d7#reply-63764b6edc823473f485b1d2)

TDD is not about code coverage, it's about how you design your code. The TD stands for "test-driven", meaning that tests are used as a tool to push implementation forward. It doesn't focus on the tests itself, they are only the measure of completion for a specific unit of code when applying TDD. The code coverage and documentation are merely welcome and useful side effects. Obviously, it takes practice and you need to know how to write tests well. The latter is true for code of any kind, but knowing how to write good tests and applying TDD can also foster better production code.

[Ákos Kőműves](https://hashnode.com/@akoskm)

[Nov 17, 2022](https://hashnode.com/posts/why-i-dont-do-tdd/6373af8a4a2eb420e8853ec0/comment/637632d9559c02733a0ad8d7#reply-63765201dc823473f485b3c2)

I don't think about test coverage in terms of covered lines when I'm doing my _kind of_ TDD.

For apps that need to be delivered fast, I write only a few integration tests to cover the main flows, nothing else.

On the other hand, I always thought that TDD is closely related to unit tests, that I rarely write for full-stack apps.

[Julian Ewers-Peters](https://hashnode.com/@ewerspej)

[Nov 19, 2022](https://hashnode.com/posts/why-i-dont-do-tdd/6373af8a4a2eb420e8853ec0/comment/637632d9559c02733a0ad8d7#reply-6378cfe8ce6f5c939e281830)

[Ákos Kőműves](https://hashnode.com/@akoskm) It all depends on the complexity of the app and the business logic. Small apps with a lot of reused (and hence tried & tested code) may need less unit tests and integration tests may be sufficient. However, I believe that practice makes perfect and it would be wise in my opinion to apply TDD whenever possible to come up with a solid code design.