Honestly, Unit tests. Based on the assumption that 💯% coverage was achieved, how many of those tests are actually testing what they are meant to test, and what does that mean for the coverage statistic.
So the answer is use humans to review code. But who really trusts humans to code, that's why we have tests?
There's an infinite number of things a piece of code could be doing, and in general tests only test that code does the things we want. But there's another infinity of things we don't want that code to do, that we're not testing for. As I'm learning more about how brittle and hard to understand large and complex systems are, the more I see the value of fuzzing, or property-based testing for smaller pieces of it.
Unit tests are good at proving that the program does what the programmer says it's going to do
Precisely, as humans make mistakes, tests also may be prone to the same (I am pro TDD to be clear, but this is always in the back of my mind).
Coverage is the biggest feel good fraud.
expect(() => foo.bar())).toThrow()
That counts as coverage, but it's (probably) useless.
I totally agree. Unit tests are another false sense of security. Having 100% code coverage does not guarantee a working functionality.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.