I am the author of the test coverage tool, and I do not believe that 100%
code coverage is the right goal. Coverage is a proxy for testing quality,
but not a guarantee of it. Getting to 100% coverage is a better indicator
of chasing metrics than of actually writing good tests. I'm happy if my
coverage gets into the 90% range, but then I try to write a lot of if
statements protecting against the impossible.
If you really do need to verify that your code works when the impossible
happens, you can do that. Say you have code like this:
err := neverFails()
if err != nil {
zounds()
return err
}
and you want to verify that zounds gets called when the impossible failure
occurs. That's a reasonable thing to want to do, and you can test for that
by writing instead:
err := neverFails()
if failureTrigger || err != nil {
zounds()
return err
}
Then you declare the variable failureTrigger and in the test write:
func TestWhatIfNeverIsToday(t *testing.T) {
failureTrigger = true
defer func() { failureTrigger = false }
call code....
test that zounds is invoked.
}
-rob
On Sun, Apr 12, 2020 at 11:55 PM Kevin Malachowski <niftasti...@gmail.com>
wrote:
> Is there a particular reason you want 100% code coverage?
>
> Not trying to start a flame war: given limited time and effort, unless the
> rest of my projects had 100% coverage already, I would personally spend my
> time working with a package with lower coverage, or just fixing known bugs.
> If your codebase has no bugs and otherwise full coverage... I have to say
> I'm jealous :)
>
> In any case, one way to test your application's handling of an error from
> that function is to fake it out during unit tests (simple example, let me
> know if you want a more thorough one:
> https://play.golang.org/p/uKGFLYVlQxz). Of course this does not test the
> "integration" of your application code and ioutil.ReadDir, but IMHO trying
> to get extremely high code coverage in non-unit tests is really a time sink.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/1908d64d-fb3f-4d73-9302-b215c49dac36%40googlegroups.com
> .
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOXNBZRz_7%3DQpWtXv%2BE1VYHvRS_SjNb%2B8-1MXOeB7Xk8r_rb3Q%40mail.gmail.com.
