Race condition between Go tests when using package global

I use a package global variable to hold the http client to be used by functions in the package. This is so that it can be replaced by a mock http client for unit tests.

Each test function creates an appropriate mock http client instance and assigns it to the package global before the rest of the test body.

The test body exercises code that starts a long-lived goroutine that references the global. This goroutine is still running when the test function is complete.

The go testing framework starts the next test function which follows the same pattern. A race condition is detected when the first goroutine reads the global which has just been written to the second function's mock http client instance.

This arises because the test framework runs the second test function in the same process as the first, and so the long-running goroutine is not killed.

What solutions are available? I would very much prefer not to add "stop" semantics to the framework with the long-running goroutine just to improve this specific aspect of testability.

The situation you've described is a common challenge when writing tests for long-lived goroutines that reference package-global state. While it might be challenging to completely avoid sharing state between test functions in the same process, there are some strategies you can use to address this issue without altering the framework or introducing "stop" semantics:

Use Test Setup and Teardown Functions: Instead of directly modifying the package global variable, you can use the TestMain function provided by the testing package to set up and tear down shared resources for your tests. You can create and assign the mock HTTP client instance in the TestMain function before running any tests, ensuring that each test starts with a clean slate.

Create a Wrapper Around the Global Variable: Wrap the package-global variable in a function that manages its state and assignment. This can help you better control access and assignment of the global variable. For example:

var httpClientMu sync.Mutex
var httpClient *http.Client

func SetHTTPClient(client *http.Client) {
    httpClientMu.Lock()
    defer httpClientMu.Unlock()
    httpClient = client
}

func GetHTTPClient() *http.Client {
    httpClientMu.Lock()
    defer httpClientMu.Unlock()
    return httpClient
}

Then, in your tests, use SetHTTPClient to set the mock HTTP client, and use GetHTTPClient to access the global variable in your code. This approach adds a level of synchronization to prevent concurrent access issues.

Use a Dependency Injection Approach: Rather than relying on package-global state, refactor your code to accept the HTTP client as a parameter to the relevant functions or methods. This makes the code more testable and eliminates the need for the package-global variable.

Consider Context: If the long-lived goroutine is making HTTP requests, consider passing a context.Context to your functions and goroutines. This allows you to control the lifecycle of the goroutine and cancel it when the test ends. Using the context package can help manage long-lived operations gracefully.

While these approaches may require some adjustments to your code, they can help improve testability and avoid issues with shared state between test functions. It's important to strike a balance between maintaining code quality and improving testability while working within the constraints of your testing framework.