Bump to this, any inputs?

You will have to clarify exactly what you want to be done differently? Do you just mean having failsafe run them rather than surefire? Or do you mean actually launching the produced application and testing against it?

I mean the difference between @QuarkusTest and @QuarkusIntegrationTest, where the tests are run against a packaged form of the app. (I would like the option to run the Cucumber in an @QuarkusIntegrationTest context)

Was I clear enough? Does that make sense?

Sure, but I am very unlikely to have the time to look at something like that.

@GregJohnStewart any progress on this topic?

I would like to get into this topic, as I think cucumber is perfect for integration tests.

I had some code working towards it, but never quite got it working, definitely worth taking another look at (esp with Quarkus 3), and could probably use some assistance getting over the issue I was having. @stuartwdouglas Any thoughts since it's not just me asking?

I would also be happy to contribute. Is there maybe something in the Quarkus core that can be used as a reference to get started?

Or do you mind sharing your code?

https://github.com/GregJohnStewart/quarkus-cucumber

The actual code for the extension is in the runtime directory. My addition I will push shortly is the CucumberQuarkusIntegrationTest class. I don't have time at the moment but next step is trying it out and remembering why this didn't work, and adjust for it. I was going to add tests in integration-tests.

@stuartwdouglas Happen to have the command used to run these tests handy? Any other notes for testing?

Also thinking this would be a good opportunity to add some examples and docs

This looks like a class loading problem.

Caused by: java.lang.IllegalStateException: Unable to locate CDIProvider
	at jakarta.enterprise.inject.spi.CDI.findAllProviders(CDI.java:139)
	at jakarta.enterprise.inject.spi.CDI.getCDIProvider(CDI.java:92)
	at jakarta.enterprise.inject.spi.CDI.current(CDI.java:65)
	at io.quarkiverse.cucumber.CucumberQuarkusBase$CdiObjectFactory.getInstance(CucumberQuarkusBase.java:170)

This looks like a class loading problem.

Caused by: java.lang.IllegalStateException: Unable to locate CDIProvider
	at jakarta.enterprise.inject.spi.CDI.findAllProviders(CDI.java:139)
	at jakarta.enterprise.inject.spi.CDI.getCDIProvider(CDI.java:92)
	at jakarta.enterprise.inject.spi.CDI.current(CDI.java:65)
	at io.quarkiverse.cucumber.CucumberQuarkusBase$CdiObjectFactory.getInstance(CucumberQuarkusBase.java:170)

I do not think that this is a class loading problem. In QuarkusIntegrationTests, CDI is not present. I kinda somewhat got it working by booting up Weld manually. Not sure, however, how to get weld to autodiscover the beans in test-scope.

EDIT:
Got autoweld working. It is not perfect; e.g. beans with only one constructor still need the @Inject annotation and @Singletons seem not to be recognized. But those seem minor.

@turing85 Thanks for taking point! Excited to see it in place. It is interesting CDI is called for, apparently.

@GregJohnStewart no problem 🙂 but as mentioned in the (updated) documentation... it's not perfect. Also, I'd like to refactor the test afterwards. I think we need multipel test modules in order to automate some testing.

Hello,
I am a new user to this quarkus extension (thank you for providing it by the way 👍 ), and I encountered the same issue when using QuarkusIntegrationTest annotation.
In my case, I don't need CDI for this kind of tests, so I tried to use the following solution, using the CucumberOptions annotation :

@QuarkusIntegrationTest
@CucumberOptions(objectFactory = DefaultObjectFactory.class)
public abstract class CucumberQuarkusIntegrationTest extends CucumberQuarkusTest {
}

Unfortunately, this is not working, and I looked at the code in CucumberQuarkusTest, it seems to be linked to this part of code:
(https://github.com/quarkiverse/quarkus-cucumber/blob/main/runtime/src/main/java/io/quarkiverse/cucumber/CucumberQuarkusTest.java#L107-L109)

ObjectFactory objectFactory = new CdiObjectFactory();
ObjectFactorySupplier objectFactorySupplier = () -> objectFactory;

The correction would be to

1. Use the RuntimeOptions.objectFactory if provided, instead of always using the CdiObjectFactory.

final ObjectFactory objectFactory = runtimeOptions.getObjectFactoryClass() != null
                ? new DefaultObjectFactory().getInstance(runtimeOptions.getObjectFactoryClass())
                : new CdiObjectFactory();

2. Add @Inherited annotation to @CucumberOptions annotation , in order to be able to create a CucumberQuarkusIntegrationTest that will hide this logic of overridden objectFactory

If you agree with this solution, I can provide a patch with changes explained

Thank you

any news on this?
cc @stuartwdouglas @christophd @tisoft

With the new 1.2.0 release - especially with the intoduction of @ScenarioScoped - this issue becomes more importance. Before, we could run some tests as @QuarkusIntegrationTests. This does not work anymore since now Arc.container() is called at the end of the execution, which will fail: https://github.com/turing85/quarkus-qr/actions/runs/12492899794/job/34860710911#step:3:2859

@stuartwdouglas @christophd (and possibly @mkouba) can we get some traction on this issue?