Influencing the Interaction

By default integration tests are run as the built-in "__system" user. But sometimes you need control over the user that executes the test matters, and so you want to specify a different user to perform the test (or change their roles, or change the time, or their locale).

The framework provides a number of options.

Using SudoService or InteractionService directly

The most straightforward option is to use the SudoService to specify the user to interact with:

sudoService.sudo(
    InteractionContext.switchUser(UserMemento.ofName("joe")),
    () -> wrap(toDoItem).completed()
);

Alternatively, you can achieve much the same thing using InteractionService, which is a slightly lower-level but more powerful service:

interactionService.run(
        InteractionContext.builder().user(UserMemento.ofName("joe")).build(),
        () -> wrap(toDoItem).completed()
);

Using @InteractAs

Rather than making an imperative call, you can use the @InteractAs annotation to declaratively indicate the user to run the test as.

@InteractAs(userName = "joe")
@Test
public void happy_case(){
    // ...
}

Using the NoPermissionChecks JUnit 5 extension

If your integration test references secman, then this will activate secman’s authorizor. Unless you have set up a seed service, chances are that the default "__system" user will have no permissions and so any calls through the WrapperFactory will likely fail.

However, any interaction made by a user with the SudoService's ACCESS_ALL_ROLE role skips permissions checks.

The NoPermissionChecks JUnit 5 extension ensures that the user has this role, effectively disabling permission checks even if secman is part of the app.

@ExtendWith(NoPermissionChecks.class)
public class MyIntegrationTest extends CausewayIntegrationTestAbstract {
    // ...
}

Using the UserMementoRefiners JUnit 5 extension

The UserMementoRefiner SPI is part of the authentication process, allowing the user memento representing the logged-on user to be tweaked. However, this SPI is not normally called during integration tests, because the authentication process is skipped (tests start executing "under the skin", so to speak).

The UserMementoRefiners JUnit 5 extension allows any available UserMementoRefiner implementations to be called. Normally these would be defined within the TestApp used to bootstrap the integration test.

For example:

@ExtendWith({UserMementoRefiners.class})
public class MyIntegTest extends CausewayIntegrationTestAbstract {

    @SpringBootConfiguration
    @EnableAutoConfiguration
    @Import({
            // ...
            MyModule.class
    })
    public static class TestApp {

        @Bean
        public UserMementoRefiner userMementoRefiner() {
            return userMemento -> userMemento.withRoleAdded(
                                    SudoService.ACCESS_ALL_ROLE.getName()); (1)
        }
    }
1 has the same effect as the NoPermissionsCheck extension, discussed earlier.