On Thu, 10 Sep 2020 at 08:15, Yvonne Zhang <yvonn...@outlook.com> wrote:

> Hi,
> I have a function streaming a zipreader to browser. It is like this.
> func functionA(....)(body io.ReadCloser, err error){
>
>    // some logic to get a zipreader
>
>    body, pipeWriter := io.Pipe()
>    zipWriter := zip.NewWriter(pipeWriter)
>
>    go func(){
>       // err := functionB(zipReader, zipWriter)call another function to
> prepare files and write to zipwriter
>    If err != nil{
>        zipWriter.Close()
>         _ = pipeWriter.CloseWithError(err)
>         return
>    }
>       zipWriter.Close()
>        pipeWriter.Close()
>    }()
>    return
> }
>
> My question is about unit test about this functionA. I have mock for
> functionB. How do I write unit test for functionA with the mock functionB.
> It seems my unit test does not work well when it goes into the goroutine.
> Many thanks!
>

For the record, my usual response to this, assuming that function A and
function B are not exported functions, is that you'd be better off not
writing unit tests for the individual functions, but testing (as far as
possible) against the publicly exported interface. I tend to think about
what the overall contract is (the contract that really matters from the
external consumer's point of view) and test that.

If you do that, then your tests will remain useful even if you decide to
refactor the code. That is a significant part of the value of automated
tests in my view.

In this particular case ISTM that the goroutine is just an implementation
detail. If you set up the stream source somehow, you could use the net/http
package to hit the endpoint that does the streaming and check that you're
seeing the correct result. Depending on what the source is, you *might* need
to fake it up somehow, but I'd always be inclined to use the lowest
available level to do that, so you're testing as much of the stack as you
can (and thus giving yourself most confidence in the code and most freedom
to refactor later).

I'm aware that in saying this, I'm going directly against unit-testing
advice available elsewhere. :) YMMV. And it's worth noting: when testing,
there are no absolutes and context is crucial for making a decision as to
what and how to test.

  hope this helps,
    rog.


> --
> 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/4ca0817a-f1f7-44a9-be3d-3584bcb61b8an%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/4ca0817a-f1f7-44a9-be3d-3584bcb61b8an%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CAJhgachcE4wpSos7rt8tELi0P3xwKyL-SKrbo6R%2BQSFbwDF2rw%40mail.gmail.com.

Reply via email to