Modified blocking return to have more intuitive behavior

[chentom88]

Instead of methods blocking by default, changed blocking return behavior to require user activation. Also created an additional channel that can be used to unblock a mock method call once it has been set to blocked.

[nelsam]

That's interesting. Give me a bit to think on it, but I like the idea.

[poy]

Could we instead take advantage of the Called channel? For instance we could fill it with a helper in eachers (much like AlwaysReturn())?

[nelsam]

@apoydence: How would that work? Do you mean something like this?

func BlockSend(calledField *chan bool) chan<- struct{} {
    oldChan := *calledField
    newChan := make(chan bool)
    *calledField = newChan
    signalUnblock := make(chan struct{})
    go func() {
        <-signalUnblock
        v := <-newChan
        oldChan <- v
        *calledField = oldChan
    }()
    return signalUnblock
}

http://play.golang.org/p/LBRhQFTdKq

There are obviously data races there, but the basic idea is to re-assign the FooCalled channel with a channel that has no buffer. The send operation will then block until a value is received from the new FooCalled channel. The helper sets up a goroutine to take care of this as soon as signalUnblock gets closed or has a value sent to it.

It would require a change to hel's mocks, too, to defer the FooCalled <- true call (or at least execute it after sending on the Input channels), but that's not a big deal.