|
|
|
|
|
|
by 1dom
261 days ago
|
|
|
> Yes, these are good. But they're a different kind of test. There are tests for correctness, and tests that the program runs. You need both. Why do you need both? Some software is so small and simple that it's possible to write a high level running/integration test that covers all the practical correctness tests that application might need too. You can say "yeah, but they'd be better if they had unit test" but that's the point being made: eventually you reach a place where more tests, even those recommended as best practice, don't actually deliver any more _real world_ value, and even make the code harder and slower to maintain. |
|
|
Sure, you don't need unit tests if you don't need unit tests because a program really is that simple. But that's an exception for tiny programs/modules, not the rule.
> eventually you reach a place where more tests, even those recommended as best practice, don't actually deliver any more _real world_ value
I explicitly said unit tests are for algorithmic code that can have logic errors. Obviously, if you've written tests for all those, you don't need any more.
> and even make the code harder and slower to maintain.
But you can trust the code is correct. Obviously this is the tradeoff, and for anything serious it's the right tradeoff.
You seem to be arguing against tests generally except for the most superficial ones. That's a recipe for buggy and often hard-to-understand, underspecified code.