On Tue, Feb 13, 2018 at 5:26 PM, Axel Wagner <axel.wagner...@googlemail.com>

> Not very, but it does depend on the details. For example, you might
> provide your own http.Transport for the client to use, or even your own
> net.Conn.

Using ioutils.ReadAll() on a HTTP request means to me to read out the
response's body. I cannot see how http.Transport and net.Conn would have
anything to do with this.

> You might have the server stop sending any data, so eventually the
> connection will timeout.

So what you're saying is that unless the response contain chunked data,
ioutil.ReadAll() will never fail?

> The question is, though, why would you want that?

As ioutil.ReadAll does return an error in its signature, i think it's good
form to test it. Don't you?

> Is that actually a path that is worth testing? Personally, I kind of doubt
> it.

That's kind of it really, i am having a hard time making up my mind here.
That's why i come for the golang nuts wisdom.

> You'll probably get more bang for your buck, if you instead send back
> broken/incomplete data from the server and see if the client handles that
> correctly.

I already test for this kind of problems in my unittests. It's more a
matter of what to do with the error return value from ioutil.ReadAll() when
i cannot see how i could ever get anything but err == nil. It might just be
me, that doesn't know enough about the ioutil.ReadAll() internals.

// Patrik

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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to