This is something I realized is that if you try to write more bullet proof code, it may have alot of extra checks in it. That may make it harder to test because there are more conditions. In theory your code is trying to cover cases that may or may not occur but it is trying to be more robust … However, then when you run something like the simplecov gem - https://github.com/colszowka/simplecov If your code has various checks in it that are not tested because they are not typical, your code module will get a bad percentage mark for not being fully tested.
I hate to say it, but that grade might be warranted.
If you have a lot of error conditions you are anticipating in a function, you should probably unit test all of those error cases to make sure they handle the errors well. Otherwise how do you know you are handling them appropriately?
It’s truly test driven development … There is no way to guarantee a program to be bug free (Turing). Even if all your code is executed by tests, it is still not executed with all possible conditions. It seems I should want to write code that satisfies the testing requirement but I am not always sure that I would feel the most confident that it covers all cases and I can’t always test all cases …
It's truly test driven development .. There is no way to guarantee a program to be bug free (Turing). Even if all your code is executed by tests, it is still not executed with all possible conditions. It seems I should want to write code that satisfies the testing requirement but I am not always sure that I would feel the most confident that it covers all cases and I can't always test all cases ..
I think the point is that any extra checks that you add for robustness should have associated tests. Otherwise you won't know that your check does what you intended should that condition ever arise.
Colin
Generally when tests are written, it seems they never cover all possible cases. When you are writing code, you might sometimes think of a case where an unlikely type of input might occur so you convert it from one type to another. Even if your code has just one or two lines that don’t get covered, that is enough to knock your coverage grade down considerably. If those particular cases seem unlikely then your most probably going to leave them out because you may not have time to try to cover every last unlikely user error that could happen … That seems to be the actual reality even if not ideal , but I don’t see any real remedy to this
It’s really easy, the remedy is to write a test everytime you find a new error condition, and then have your method satisfy that test.
If you are not writing a test everytime you are attempting to handle an identifiable user error, what are you doing exactly? How are you solving the error without making sure that the error handler works?
If you can’t test the error conditions that you are anticipating, you might not want to rescue from them.
Additionally, it sounds like you are being far too accepting with your API. Have some rules about what input types you accept, and leave it at that. If there’s the need to process another input type, you can always provide another
function that decorates your original after converting the type appropriately. There’s a difference between a “user” who is a developer ( I would argue that is not a user ), and an actual “user” of your website or program.
