When you are calling your assertion in a test, you do have access to the current client, so I don't see the benefit of this new method (which makes difficult to understand what's going on IMHO).

Yes I agree that the benefits are small, though someone at some points made the decision to be able to call browser kit assertions without passing any arguments, instead acting on the internal state of the test class (e.g.self::assertResponseIsSuccessful(),self::assertBrowserHasCookie(..), etc.).

For the sake of consistency I would like to be able to do the same for my own assertions (e.g.self::assertResponseMatchesOpenApiSchema() instead ofself::assertResponseMatchesOpenApiSchema($client) orself::assertResponseMatchesOpenApiSchema($method, $path).

If I hadn't needed the request method and path this would have been completely possible usingBrowserKitAssertions::assertThatForResponse(), which does the same thing for theResponse object as the newBrowserKitAssertions::assertThatForBrowser() method does for theAbstractBrowser.

Thank you@koenreiniers.