Too many error checks in your code may result in bad coverage grade

[Jedrin]

 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.

 

[Stewart Mckinney]

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?

On Wed, Jun 22, 2016 at 3:25 PM, Jedrin <jrub...@gmail.com> wrote:

 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.

 

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/06cd4973-136c-4af4-947e-086f716105b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jedrin]

 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 ..

[Colin Law]

On 22 June 2016 at 21:02, Jedrin <jrub...@gmail.com> wrote:
>
> 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

> https://groups.google.com/d/msgid/rubyonrails-talk/014f8b69-a751-4993-8dcc-20680a48e837%40googlegroups.com.

[Jedrin]

 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

[Stewart Mckinney]

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.

On Wed, Jun 22, 2016 at 4:13 PM, Jedrin <jrub...@gmail.com> wrote:

 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

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/eb44a9dc-a4ec-40ed-a142-e4b33882a11e%40googlegroups.com.