如何告诉我的测试等待goroutine中的回调？

Question

I am using the dockerclient https://github.com/samalba/dockerclient which has a channel-based API to listen for events client.MonitorEvents() and a convenient callback method client.StartMonitorEvents(callbackHandler).

I want to test that the handler gets called. Of course, the dockerclient handles the events in a goroutine.

For now, my handler just spits out a log. If I wait in my test, everything is handled. If I do not, it exits before it handles anything:

func eventCallback(event *dockerclient.Event, ec chan error, args ...interface{}) {
  log.Printf("Received event: %#v
", *event)
}

My test seems straightforward:

func TestReceiveEvent(t *testing.T) {
   createAndMonitorEvents(server.URL)
   <- eventReady
   eventWriter.Write([]byte(someEvent))
   // test for something here
}

Of course, it doesn't work unless I put in a time.Sleep() because of the goroutine.

How do I tell my test, "wait for the other routine to do its work before running the test", other than putting in some arbitrary sleep? I am looking to test that the event is processed correctly by my handler.

The alternate interface, client.MonitorEvents() returns a channel, which gives me greater control, but the receive off the channel spits out infinite nil events.

UPDATE:

As requested, createAndMonitorEvents is:

func createAndMonitorEvents(url string) {
  // Init the client
  docker, _ := dockerclient.NewDockerClient(url, nil)

  // Listen to events
  stopchan := make(chan struct{})

  go func() {
    eventErrChan, err := docker.MonitorEvents(nil, stopchan)
    if err != nil {
        return
    }

    for e := range eventErrChan {
        if e.Error != nil {
            return
        }
        eventCallback(&e.Event, nil)
    }
    fmt.Println("monitor in place")
  }()
}

Answer 1

I think when you get nils with MonitorEvents, you're just seeing that the event channel is closed (the source of MonitorEvents includes a close(eventOrErrorChan), supporting this). evt, ok := <-c lets you directly check if that (ok will be false when it's closed), and for evt := range c will stop after it's closed. In general, receiving from a closed channel is specified to "[yield] the element type's zero value after any previously sent values have been received"

On the question about waiting on a callback: the callback can close a channel. (Or send to it.) Then your test can wait up to a specified length of time with a select:

select {
case <-c:
        /* ...success... */
case <-time.After(5 * time.Second):
        /* timed out */
}

If you know some error conditions cause the handler not to finish, or not to run, it could signal those situations on a different channel, or by sending a different value to c.