PicoContainer injection in @BeforeAll and @AfterAll hooks

[chabala]

Hello. I was excited to try the @BeforeAll and @AfterAll hooks in cucumber-jvm 7.X, but I've hit a snag.

The annotations insist they should be on static methods, but the test actions I want to do really need some objects injected from the PicoContainer. It seems the glue class I made for the hooks doesn't get instantiated at all.

I've tried moving them from constructor injection to annotated static fields, but they don't seem to be getting injected.

[mpkorstanje]

Dependency injection with Pico container is scoped to the scenarios life cycle. This ensures that state is not accidentally shared between scenarios. But without an active scenario there is also no dependency injection context to inject from. This is something I've been wanting to improve for a while now but there are other problems to solve first.

Now you didn't mention what your concrete problem is, but here are some options:

1. Use a @Before hook and implement the exactly once semantics yourself.
2. Switch to cucumber-spring and create a @Component with a @EventListener(ContextStartedEvent.class) annotated method. This will allow you to access the application scoped beans and do any additional setup but not the scenario scoped beans (as expected). Unlike PicoContainer, the application scope is reused between scenarios.

[chabala]

Yeah, I'm not super excited about either of those options. I'll always choose the Spring-free option if there's a choice.

I have some feature files that are trying to do some 'invoke around' behavior of the rest of the Cucumber suite, and they're doing it by relying on file name ordering. I would very much like to not do it that way, as I see that as an impediment to parallelization, because I doubt I'll have any more control on making specific features run first and last consistently.

I've already done the 'make your own ObjectFactory' for long-lived fixtures with PicoContainer: https://jonbake.com/blog/2021/03/10/cucumber-jvm-fixture-data.html

[chabala]

Using a @Before hook and only calling the desired code once is not too challenging, and I suppose if I also let it increment a semaphore, then my @After hook could know when it was in the final callback. Wait, no, that still wouldn't work, I guess I'd have to pair it with the @AfterAll. It just feels like I'm not taking advantage of the framework feature that was designed for my use case.

[mpkorstanje]

There wasn't that much design involved. Much like JUnit, the @{Before,After}All hooks were designed to allow you to setup and tear down static fields, not much more.

What you're looking for is more like a copy of JUnit Jupiters Test Lifecycle Callbacks which have a hierarchical context. This context could then be used to store PicoContainers Scoped Containers.

I have some feature files that are trying to do some 'invoke around' behavior of the rest of the Cucumber suite, and they're doing it by relying on file name ordering. I would very much like to not do it that way, as I see that as an impediment to parallelization, because I doubt I'll have any more control on making specific features run first and last consistently.

Ah I see.

I've had a similar situation and I changed the step definitions so that they would work with "just-in-time" setup. If a fixture was needed, a step definition would call that fixture as if it was setup for the first time. The implementation then ensured that this call would happen exactly once and then return a cached instance for all subsequent calls.

Caches would then be cleaned up with an @AfterAll hook.

Something like this, where UserService is injected into steps as it would normally:

public class UserService {

    private static Cache<Long, User> cache = ....  

    public User getDefaultUser() {
        synchronize(cache) {
              return cache.get(1, id -> httpClient.get("https://api.exmaple.com/users/" + id)));
        }
     }

    @AfterAll
    public static cleanup() {
          // Clean up cache entries here
     }
}

This also had the advantage of cutting down time spend on setting up fixtures that weren't going to be used when running a limited set of features.

[chabala]

So, I did use the @Before hook, implementing the only-once logic myself, and paired it with the @AfterAll hook. I have to stash an object into a static variable so that it will still be available in the after hook.

I'm left wanting more features in the hooks. I can't log anything about what happened in the after hook into the test report, even if I have a Scenario object from the last scenario, so I'd really like some kind of outside-the-scenarios object to write to that the reporting would surface. Would it be easier if the hooks weren't static, and they participated in dependency injection? Yeah, it would.

I also really wish I could use Gherkin for the @BeforeAll & @AfterAll too, instead of translating it into the Java steps.