How test functions are called in Go?

I'm studying Go language and I have a question now.

I was just testing buffered and unbuffered channels.

While writing the test code for it, a situation occurred that I couldn't understand the result.

func BenchmarkUnbufferedChannelInt(b *testing.B) {
	ch := make(chan int)
	go func() {
		for i := 0; i < b.N; i++ {
			ch <- i
		}
	}()

	for {
		<-ch
	}
}

The above code doesn't stop, because <-ch makes the goroutine blocked forever. However, the code below does not create an blocked status and the testing succeeds.

func BenchmarkUnbufferedChannelInt(b *testing.B) {
	ch := make(chan int)
	go func() {
		for {
			<-ch
		}
	}()

	for i := 0; i < b.N; i++ {
		ch <- i
	}
}

BenchmarkUnbufferedChannelInt
BenchmarkUnbufferedChannelInt-12         8158381               142.1 ns/op
PASS

As far as I know, there is no parent-child relationship between goroutines, so the termination of one goroutine does not affect the termination of the other goroutines except for main goroutine.

Theoretically, both of the above codes should eventually be blocked forever.

But I don't know why only the second code succeeds.

I wonder how Go calls test functions. Assuming that the goroutine where the test function runs has the same characteristics as the main goroutine, I can understand the result of the above codes.

But if not, I don't understand. In both tests, a goroutine should eventually be blocked forever.

Can you explain the above result? please!

> The above code doesn't stop, because <-ch makes the goroutine blocked forever.

No, it's being blocked because of the infinite for loop.

> However, the code below does not create an blocked status and the testing succeeds.

Right, because the for loop runs for as many loops as you want your benchmark to run. Once this loop ends, the goroutine you spun up is forgotten and you have a leak. See https://www.ardanlabs.com/blog/2018/11/goroutine-leaks-the-forgotten-sender.html: If you start a Goroutine that you expect to eventually terminate but it never does then it has leaked.

In your second example, the goroutine blocks indefinitely, which is technically a leak but won't block the program itself.

In your first example, you're looping indefinitely outside a goroutine, so the program will block. This isn't specific to Go and isn't really related to receiving from the channel. You're just looping with no exit condition e.g. while (true) {} in about any other language.

Make sure you aren't looping indefinitely in the goroutine to prevent it from leaking. Also, ranging over a channel stops once the channel is emptied and closed, so you can close it in the goroutine once done filling it and range over it instead:

func BenchmarkUnbufferedChannelInt(b *testing.B) {
    ch := make(chan int)
    go func() {
        for i := 0; i < b.N; i++ {
            ch <- i
        }
        close(ch)
    }()

    for _ := range ch {

    }
}

I figured out why this happened.

First example: Deadlock occurs because <-ch statement is used even though there is no more data to consume because the producer goroutine iterates more times than the producer goroutine iterates. Even if the consumer goroutine is terminated, the program itself in which the test function is running does not terminate, so deadlock eventually occurs.

Second example: The number of iterations of the consumer goroutine is less than the number of iterations of the producer goroutine. When the loop of the consumer goroutine is finished, the corresponding test function returns and the program ends. At this time, the loop of the producer goroutine has not finished yet, but the program itself has ended, so a goroutine leak occurs.

It took me a long time to understand the situation, thank you all for your replies.