I hear what you're saying - we now have PR #48312 that leaves everything as is and only cleans up the unwanted selenium handling (that should not have been added in the first place)

There is one section of code in OID4VCAuthorizationDetailsFlowTestBase that is not ideal ...

            AuthorizationEndpointRequest authRequest = authRequestSupplier.get();
            authRequest.openLoginForm();
            String currUrl = oauth.getDriver().getCurrentUrl();
            if (currUrl != null && !currUrl.contains("error=") && !currUrl.contains("error_description=")) {
                oauth.fillLoginForm(ctx.getHolder(), TEST_PASSWORD);
            }
            AuthorizationEndpointResponse authResponse = oauth.parseLoginResponse();

The required condition check has moved out as far as the test case itself. That works for me as long as we don't see that repeated over and over.

As you can see the AuthorizationEndpointRequest comes from a supplier, the code cannot know the outcome of open() before it makes the call.

The question for me is: how do we handle the case when the authorization request is been given to a piece of code that cannot know in advance whether it is correct or not - we will have to deal with that question somewhere.

When looking at the above, its important to realize that openLoginForm() already has the information about whether it succeeded or not, only that the caller does not get it.

I've merged the #48312 as it is better than what we have in main IMO. Thanks for that PR!

+1 that the code you mentioned in OID4VCAuthorizationDetailsFlowTestBase is still not ideal.

As you can see the AuthorizationEndpointRequest comes from a supplier, the code cannot know the outcome of open() before it makes the call.

The question for me is: how do we handle the case when the authorization request is been given to a piece of code that cannot know in advance whether it is correct or not - we will have to deal with that question somewhere.

I think the test should always know what it expects and whether it expects login-form to be shown or not.

I've addressed the problem you mentioned in the OID4VCAuthorizationDetailsFlowTestBase in my PR to your branch tdiesler#3 . It is solved by adding another function authzResponseSupplier to the method runAuthorizationDetailsTest, so test can "hint" whether it expects login-form or not . So many "suppliers" and "functions" are maybe not ideal for the runAuthorizationDetailsTest , but that is the problem already on that method (question is, whether it is not easier to just avoid that method runAuthorizationDetailsTest and rather extract the things into the individual tests themselves, but not 100% sure it is easier or not)

I think the test should always know what it expects and whether it expects login-form to be shown or not.

Ok, I'll go with that notion for now - in which case we indeed need to pass the auth request around together with a flag that marks it as invalid. The server side AuthorizationEndpointRequest has a similar helper property (i.e. invalidRequestMessage)

In general: the test should know whether it is supposed to show the error-page, redirect to the client or have the login form. IMHO that is one of the points of the "Fluent API" and composition used here. Caller can use something like open() followed by other things when you expect login-page to be shown. And caller use doLogin(username, password just in case that login form is really expected to be shown and redirect to the client right after submit username/password.

The test you mentioned can be probably rewritten to something like this (did not tried to run it, just for illustration). This doesn't use any timeout:

    public void testWrongEncryptionAlgorithm() throws Exception {
       
            ClientResource clientResource = AdminApiUtil.findClientByClientId(adminClient.realm(oauth.getRealm()), oauth.getClientId());
            ClientRepresentation clientRep = clientResource.toRepresentation();
            OIDCAdvancedConfigWrapper.fromClientRepresentation(clientRep).setRequestObjectEncryptionAlg(RSA_OAEP_256);
            clientResource.update(clientRep);
            
            // Test incorrect algorithm. Error page shown
            oauth.loginForm().request(createEncryptedRequestObject(RSA_OAEP)).open();
           errorPage.assertCurrent();

            // Test correct algorithm
            oauth.loginForm().request(createEncryptedRequestObject(RSA_OAEP_256)).doLogin("test-user@localhost", "password");
            appPage.assertCurrent();
}