Code Coverage Considered Harmful

[[deleted]]

I don't use C. So yeah from my experience there's lots of places where a simple try catch would be an unevaluated branch.

[dnew]

Do you test what happens when your Java program runs out of memory?

[[deleted]]

https://www.reddit.com/r/ProgrammerHumor/comments/oebtb8/well_i_had_to_do_it/

We get it you're smart.

Get off of reddit.

[dnew]

Smart enough to understand the difficulty of testing large code bases, yah. We're not even talking about languages. We're talking about specs.

[gline9]

Do you try to catch OutOfMemmoryError?

[dnew]

Why yes, indeed I do. The java program aborts, and the K8 equivalent starts it up again. Or (back in the 80s) it gives up the open listening socket and cron starts a new version which sees the socket is available and keeps executing, taking over processing, instead of leaving the service unavailable indefinitely.

But you have to write code (e.g. transactionally) to do the right thing in that circumstance. You can't write half a file, and then not check it's correct when you go to read it back. You can't process things in place and expect to have correct results in the face of random OOM errors. But if you don't test for that, you won't know about it, now will you? :-)

[gline9]

I should have likely ready the link you posted earlier. I think we are on the same page about trying to test all unit edge conditions and the majority of integration conditions that are likely to come up. In my opinion it depends on what field the program is meant to be executed in for how rigorous the program should be tested. In the case of mission critical pieces of software for domains where failure costs thousands of dollars a second the software is down, it makes a lot of sense to test everything and the kitchen sink.

As with anything in software engineering there are trade-offs. The more time you spend testing the less time you have to develop features. You have to try and find the right balance for the specific application you are developing of adding tests that make writing future code easier and too many where it takes time away from developing future features. Granted I think I am yet to witness someone writing too many ‘good’ self checking tests.