3 ms·

> TDD itself is also overrated, as writing testable code is much more important than the actual tests. Indeed, that is exactly the point of unit test and code

> TDD itself is also overrated, as writing testable code is much more important than the actual tests. Indeed, that is exactly the point of unit test and code coverage: proving that your code is well organized and testable through its API. > This is why getting artificial intelligence projects to create basic tests isn’t the impressive accomplishment people seem to think it is. Also correct. Additionally, the point of unit tests is to document, to show the code's use case. It's generally not possible to device intent (why) from implementation (how), but if the AI were magically able to deduce that that's a sign that the code is either trivial, or plagiarized (or both). > By embracing a more holistic testing approach, teams can deliver better software faster. Sure, if velocity is your objective. Another approach is to stop and think about whether you're testing in internal (unit test) or external (integration, acceptance test) quality. As a developer, I use unit tests primarily to verify complicated business logic to prevent the embarrassment of obvious flaws in my code further downstream.

haspok 3y ago
> > TDD itself is also overrated, as writing testable code is much more important than the actual tests. > Indeed, that is exactly the point of unit test and code coverage: proving that your code is well organized and testable through its API. You can have 100% unit test code coverage and your code can still be absolute sh*t and do absolutely nothing useful. Also, your code can work, with 100% unit test coverage, and have the tests test nothing useful. So reasoning about the quality of your code through the quantity of your unit tests is highly suspicious. And btw, TDD does not advocate code quality and well organized code - if anything, it lends itself to the opposite.
- pipo234 3y ago
  > 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...

haspok 3y ago

> > TDD itself is also overrated, as writing testable code is much more important than the actual tests. > Indeed, that is exactly the point of unit test and code coverage: proving that your code is well organized and testable through its API. You can have 100% unit test code coverage and your code can still be absolute sh*t and do absolutely nothing useful. Also, your code can work, with 100% unit test coverage, and have the tests test nothing useful. So reasoning about the quality of your code through the quantity of your unit tests is highly suspicious. And btw, TDD does not advocate code quality and well organized code - if anything, it lends itself to the opposite.

pipo234 3y ago
> 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...