Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@vaceksimon
Copy link
Contributor

@vaceksimon vaceksimon commented Jul 15, 2024

The test framework supports injecting multiple instances of the same resource type. These instances must have a different ref (an identifier for instances). If an instance does not have a ref, a "default" value is assigned. There can be only one instance of a given type without a specified ref in the test class.

The ref identifiers are unique only to the type of an instance. That means this is valid:

@TestRealm
RealmResource realm;    // ref="default"

@TestClient
ClientResource client;    // ref="default"

@TestUser
UserResource user;    // ref="default"

@TestRealm(ref="anotherOne")
RealmResource realm2;    // ref="anotherOne"

@TestClient(ref="anotherOne")
ClientResource client2;    // ref="anotherOne"

@TestRealm
RealmResource realm3; // ref="default"

In this case realm == realm3

If there is a deployed instance found that could fit the requested instance, the Registry has the following behavior to the deployed instance:

same ref? same config? same lifecycle? result
yes yes yes reuse
yes yes no destroy and create a new one
yes no yes destroy and create a new one
yes no no destroy and create a new one
no - - keep and create a new one

TestWebDriver, TestAdminClient, KeycloakIntegrationTest, and TestPage are ignored in this PR.

Realms, clients, and users have their names set to their ref.

As this should lay down the basic concept of multiple instances of the same type being deployed within the framework, other issues may follow, for example:

  • add a mechanism to specify to which realm a client and a user belong with the realm-ref attribute in the annotation
    @TestUser(realm-ref="realmWithUsers")
  • allow multiple instances of the same page class

Closes #30613

Copy link
Contributor

@stianst stianst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this can be implemented a bit more cleanly, especially with some of the changes in #31406.

@vaceksimon vaceksimon force-pushed the test-poc-multi-instances branch from b06a5f2 to 6194637 Compare July 22, 2024 13:39
@vaceksimon vaceksimon requested a review from stianst July 22, 2024 14:19
@vaceksimon vaceksimon marked this pull request as ready for review July 22, 2024 14:20
@vaceksimon vaceksimon requested a review from a team as a code owner July 22, 2024 14:20
Comment on lines 150 to 153
if (getDeployedInstance(requestedInstance) != null) {
throw new RuntimeException("Instance ref redefinition: " + requestedInstance.getRef());
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you elaborate on this? When/why would this happen?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could happen whenever someone uses the same ref or when they don't use ref at all. This check can probably be moved elsewhere, I find it comfortable here, in this loop.

@KeycloakIntegrationTest
public class MyTestClass {
    @TestRealm
    RealmResource realm1;

    @TestRealm
    RealmResource realm2;
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we discussed on the chat, there's nothing wrong in doing that, and it should just end up with realm1 == realm2.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's not necessary too, but it may be useful for debugging to just print some warning instead throwing exception. WDYT?

@vaceksimon vaceksimon requested a review from stianst July 23, 2024 09:41
Copy link
Contributor

@jonkoops jonkoops left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Comment on lines +34 to +41
Assertions.assertEquals("default", realm1.toRepresentation().getRealm());
Assertions.assertEquals("default", realm2.toRepresentation().getRealm());
Assertions.assertEquals(realm1, realm2);

Assertions.assertEquals("another", realm3.toRepresentation().getRealm());

Assertions.assertEquals("client1", client.toRepresentation().getClientId());
Assertions.assertEquals("default", client2.toRepresentation().getClientId());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to make assertions about the internals of the framework, perhaps this should be part of the framework module?

Copy link
Contributor

@lhanusov lhanusov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

stianst added a commit to stianst/keycloak that referenced this pull request Jul 25, 2024
…eycloak#31293)

* Testsuite PoC - Injection framework support for multiple instances

Closes keycloak#30613

Signed-off-by: Simon Vacek <[email protected]>

* Add unit tests for multiple instances

Signed-off-by: stianst <[email protected]>

* Remove check for ref redefinitions

Signed-off-by: Simon Vacek <[email protected]>

---------

Signed-off-by: Simon Vacek <[email protected]>
Signed-off-by: stianst <[email protected]>
Co-authored-by: stianst <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Testsuite PoC - Injection framework should support multiple instances configured differently

4 participants