Thread by @thealexkates

There are a lot of 🔥 takes out there about Test-Driven Development (#TDD)

Let's bust 5 of the most common myths! 🧵 👇

Myth 1️⃣: TDD takes too long.

Yes, you will spend a bit more time upfront writing tests versus just writing production code.

However, typing is not the bottleneck for developers. Manually verifying a system works takes way longer.

Myth 2️⃣: TDD is just about writing tests.

With TDD, tests are the means to the end. TDD is all about writing production code in a different way.

1. Write a small, failing test.
2. Write just enough code to make the test pass.
3. Refactor.

Myth 3️⃣: 100% Code coverage is the goal.

With TDD, it's all about quality over quantity. Code coverage only tells you what code isn't covered.

It's very easy to write a test that doesn't actually cover a use case. Use code coverage tools carefully!

Myth 4️⃣: TDD replaces the need for QA.

TDD is a development technique. It does not replace the need for integration, functional and exploratory testing.

Myth 5️⃣: TDD means we don't need to do architecture.

Yes, you will think about architecture a bit differently when you do TDD. However, having a high-level idea of the system and software architecture is still important to ensure a cohesive codebase.