Clear and recreate already resolved container services during unit test

[nagmat84]

Normally, i.e. in production mode, the whole Laravel application is spun up anew for each HTTP request. This implies that all services which are resolved by the global application object are re-resolved for each request and their constructors get called. During unit tests the global application object remains the same for all tests and each service class is resolved at most once when it is needed for the first time. While caching of objects of service classes in the application container is typically preferred due to efficiency reasons, it makes unit test to behave differently than real requests, i.e.

class MyTest extends TestCase {
  public function testSomething {
    $this->postJson('/api/foo');
    // in reality, the application container would be re-created between these two calls,
    // but not for unit tests
    $this->postJson('/api/bar');
  }
}

may produce a different outcome during unit tests than it would do in reality. The question is:

How do I ensure that the application container and the resolved services are re-resolved between HTTP request during unit test as they would in reality?

---

Specific example

The AuthManager is a service which is once resolved by the application container. In turn, the AuthManager is responsible for resolving Guards and caches a resolved Guard internally. When a Guard is resolved for the first time, it is constructed. The call flow is basically as follows:

1. AuthManager::guard(); serves guard from cash guards if available, calls resolve otherwise
2. AuthManager::resolve() creates the requested Guard by name and calls its creation method, e.g. createSessionDriver
3. AuthManager::createSessionDriver() creates the actual Guard (here: SessionGuard) and also sets the current request on the Guard

Normally, i.e. in a production environment the code above works as expected. As for each request the whole application is re-created, an instance of AuthManager is re-created for each request. Consequently, the array of resolved Guards is initially empty for each request and gets created for each request and therewith bound to that request.

During tests the application container survives, the AuthManager survives and so do the resolved Guards. In this specific example, this means the Guard remains bound to the very first request and resolves the user according to the first request not the currently tested request.

[danclarkdev]

Hey - been a while, but I just came across this - I had a bug whereby my user successfully resolved on the first hit to my application, but got stuck in a weird state of schrodinger's auth from that point onwards (using a separate API for our auth, but setting session & cookie values to allow login persistence across multiple sites)

I fixed the issue but wanted to add a test to cover it, which meant hitting my application with a certain cookie & session state on the first request, then a different cookie & session state on a second request (simulating someone hitting the app having logged into another of our sites, being auto logged in, then refreshing).

Anyway, I came across Auth::forgetGuards()- does the job for me and may do for you too... if you're still stuck over 2 years later! Forces the guard to be re-resolved as if you're hitting a new application instance