> You can have 100% unit test code coverage and your code can still be absolute sh*t and do absolutely nothing useful. Totally true. But give me those unit tes

> You can have 100% unit test code coverage and your code can still be absolute sh*t and do absolutely nothing useful. Totally true. But give me those unit tests, and I can tell that the code is sh*t. If I have trouble understanding the source, it could be because it's doing complicated stuff. It could be highly optimized. It could I'm too dumb. If I have trouble understanding the unit tests demonstrating what the code does, there is either something wrong with the tests or the implementation. Fix it, rinse repeat. I wasn't saying that unit tests or code coverage are a panacea or that TDD guarantees great code. But it's a tool. It's better than writing documentation, but it serves more or less the same purpose. Sometimes it's useful, sometimes not. And its complete absence is usually a bad smell. I think Michael Feather's book demonstrates how code improves by simply making it testable https://www.oreilly.com/library/view/working-effectively-with/0131177052/ https://www.oreilly.com/library/view/working-effectively-wit...