I like this solution better than Ian's, thank you.
If I can't eliminate an error, or fake it, add a new one. :).
On 4/12/20 4:04 PM, Rob Pike wrote:
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 <mailto: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
<https://urldefense.com/v3/__https://play.golang.org/p/uKGFLYVlQxz__;!!NEt6yMaO-gk!Q4voRHj3SWlaYt1nodC8rTR7L45l2HvAB7Uh-4cSyeBN1mHabEHVN0ShlvZZd5ekSQ$>).
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
<mailto:golang-nuts%2bunsubscr...@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
<https://urldefense.com/v3/__https://groups.google.com/d/msgid/golang-nuts/1908d64d-fb3f-4d73-9302-b215c49dac36*40googlegroups.com__;JQ!!NEt6yMaO-gk!Q4voRHj3SWlaYt1nodC8rTR7L45l2HvAB7Uh-4cSyeBN1mHabEHVN0ShlvaR-ZnBXA$>.
--
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
<mailto: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
<https://urldefense.com/v3/__https://groups.google.com/d/msgid/golang-nuts/CAOXNBZRz_7*3DQpWtXv*2BE1VYHvRS_SjNb*2B8-1MXOeB7Xk8r_rb3Q*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSUlJQ!!NEt6yMaO-gk!Q4voRHj3SWlaYt1nodC8rTR7L45l2HvAB7Uh-4cSyeBN1mHabEHVN0ShlvY8sdEECw$>.
--
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/920f13fe-48ed-bbcc-926c-9351877b4180%40juniper.net.
