Popular posts

IMHO, since TDD focuses too much on code implementation and is tightly coupled with the code (simply, method names and parameters must match), this metric still does not mean you're safe.

If your tool allows you to see the lines of code covered by tests, you can use it to see the parts of the code that are NOT covered by any test - then you can write, if necessary, some more tests.

However, in general I think that following the Test Diamond strategy is more beneficial (if you don't know what it is, here's a short introduction: code4it.dev/architecture-notes/testing-pyramid-vs… )

Davide Bellone Yes, I have read your article about the diamond strategy, and I feel it doesn't quite fit with TDD. Test-driven development isn't just about testing; it's more about the development process as a whole. However, I do agree with your point about the importance of integration and end-to-end tests—these are crucial in the TDD approach as well. I find it challenging and expensive to cover numerous cases with integration or e2e tests. As you mentioned in your example, many cases were left untouched, even with a simple scenario. This issue becomes even more pronounced in complex enterprise-level applications, where the number of variables and potential cases for integration tests grows exponentially.