It’s not exhaustive because complex multi-threaded software has a plethora of hidden edge cases, many of which actually fall outside the traditional remit of a unit test.
This is where other forms of software testing come into play. Such as integration tests.
wtf is a hidden edge case? Is that like flying a plane with blinders on? Come on...
You write tests to cover edge cases. If you miss one, you write more tests when you come across them. This isn't magic.
> If you miss one, you write more tests when you come across them.
…before such point you have hard to find bugs in your software.
And that’s the crux of everyone’s argument against your “just write better code” fallacy ;)
> This isn't magic.
No it’s not. That’s why people disagree with your assessment that unit tests can catch every type of bug.
If unit tests really were that magical then we wouldn’t need for other methods of tests.
I mean, do you even know what a unit test is? It’s meant to be self-contained but the problem with multithreaded code is that you can start to introduce side effects that happen outside that functions scope.
I’ve got exactly that issue right now calling OS APIs from cgo. Some of those APIs (particularly with SDL) are very thread sensitive and you cannot unit test for that because the problem lies outside that functions scope. So the only way to test for that is with e2e or integration tests instead.
I didn't say "just write better code", I said write more tests. Writing those tests will produce better code.
I also never said unit tests were the ONLY tests.
But you were ONLY talking about unit tests for catching concurrency bugs; bugs which often fall outside the scope of a unit being tested.
Nobody disagrees with your point about the importance of unit tests. But the way you present that point is more than a little naive (and that’s the polite way of putting it).