Alpha5 and TestNG DataProvider

[bschroeder]

Hey there,

i have some question regarding the TestNG DataProvider and Arquillian. I have a test like the one below that works fine with Alpha4 using TestNG Version 5.14.6 and arquillian-weld-se-embedded-1 Version 1.0.0.Alpha4.

@Inject
private BeanUnderTest beanUnderTest;
@Deployment
public static JavaArchive createDeployment() {
    return ShrinkWrap
        .create(JavaArchive.class, "test.jar")
        .addClasses(BeanUnderTest.class, BeanUnderTestDependencyMock.class)
        //Alpha4 .addManifestResource(new ByteArrayAsset("<beans/>".getBytes()),
        .addAsManifestResource(new ByteArrayAsset("<beans/>".getBytes()),
            ArchivePaths.create("beans.xml"));
}
@Test(dataProviderClass = MyObjectCreator.class, dataProvider = "data")
public void transformTest(final MyObject myObject) {
    MyTranformedObject mto = beanUnderTest.transform(myObject);
    /* ... assertions ... */
}

Method from data prvider class:

@DataProvider(name = "data")
public static Object[][] data() {
    MyObject myObject1;
    MyObject myObject2;

    /* ... */
        
    return new Object[][] { { myObject1}, {myObject2} };
}

If I try to run this test setup with Alpha5 the following Exception is thrown:

org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308 Unable to resolve managed beans for Types: [class 
de.test.package.MyObject]; Bindings: [@javax.enterprise.inject.Default()]
    at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:807)
    at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:793)
    at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.getInstanceByType(CDIInjectionEnricher.java:81)
    at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.resolve(CDIInjectionEnricher.java:71)
    at org.jboss.arquillian.impl.execution.LocalTestExecuter.enrichArguments(LocalTestExecuter.java:98)
    at org.jboss.arquillian.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:63)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.jboss.arquillian.impl.core.ObserverImpl.invoke(ObserverImpl.java:90)
    at org.jboss.arquillian.impl.core.EventContextImpl.invokeObservers(EventContextImpl.java:98)
    at org.jboss.arquillian.impl.core.EventContextImpl.proceed(EventContextImpl.java:80)
    at org.jboss.arquillian.impl.core.ManagerImpl.fire(ManagerImpl.java:126)
    at org.jboss.arquillian.impl.core.ManagerImpl.fire(ManagerImpl.java:106)
    at org.jboss.arquillian.impl.core.EventImpl.fire(EventImpl.java:67)
    at org.jboss.arquillian.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:61)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.jboss.arquillian.impl.core.ObserverImpl.invoke(ObserverImpl.java:90)
    at org.jboss.arquillian.impl.core.EventContextImpl.invokeObservers(EventContextImpl.java:98)
    at org.jboss.arquillian.impl.core.EventContextImpl.proceed(EventContextImpl.java:80)
    at org.jboss.arquillian.impl.client.ContainerDeploymentContextHandler.createContext(ContainerDeploymentContextHandler.j
ava:133)
    at org.jboss.arquillian.impl.client.ContainerDeploymentContextHandler.createTestContext(ContainerDeploymentContextHandl
er.java:120)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.jboss.arquillian.impl.core.ObserverImpl.invoke(ObserverImpl.java:90)
    at org.jboss.arquillian.impl.core.EventContextImpl.proceed(EventContextImpl.java:87)
    at org.jboss.arquillian.impl.TestContextHandler.createTestContext(TestContextHandler.java:82)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.jboss.arquillian.impl.core.ObserverImpl.invoke(ObserverImpl.java:90)
    at org.jboss.arquillian.impl.core.EventContextImpl.proceed(EventContextImpl.java:87)
    at org.jboss.arquillian.impl.TestContextHandler.createClassContext(TestContextHandler.java:68)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.jboss.arquillian.impl.core.ObserverImpl.invoke(ObserverImpl.java:90)
    at org.jboss.arquillian.impl.core.EventContextImpl.proceed(EventContextImpl.java:87)
    at org.jboss.arquillian.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:54)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.jboss.arquillian.impl.core.ObserverImpl.invoke(ObserverImpl.java:90)
    at org.jboss.arquillian.impl.core.EventContextImpl.proceed(EventContextImpl.java:87)
    at org.jboss.arquillian.impl.core.ManagerImpl.fire(ManagerImpl.java:126)
    at org.jboss.arquillian.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:101)
    at org.jboss.arquillian.testng.Arquillian.run(Arquillian.java:102)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.testng.internal.MethodInvocationHelper.invokeHookable(MethodInvocationHelper.java:189)
    at org.testng.internal.Invoker.invokeMethod(Invoker.java:666)
    at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846)
    at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170)
    at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
    at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
    at org.testng.TestRunner.runWorkers(TestRunner.java:1125)
    at org.testng.TestRunner.privateRun(TestRunner.java:749)
    at org.testng.TestRunner.run(TestRunner.java:600)
    at org.testng.SuiteRunner.runTest(SuiteRunner.java:317)
    at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:312)
    at org.testng.SuiteRunner.privateRun(SuiteRunner.java:274)
    at org.testng.SuiteRunner.run(SuiteRunner.java:223)
    at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
    at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
    at org.testng.TestNG.runSuitesSequentially(TestNG.java:995)
    at org.testng.TestNG.runSuitesLocally(TestNG.java:920)
    at org.testng.TestNG.run(TestNG.java:856)
    at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:110)
    at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:205)
    at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:174)

So isn't it possible to run many test cases with a TestNG DataProvider in Alpha5 or am I doing something wrong?

[aslak]

Your hitting this issue it seems: https://issues.jboss.org/browse/ARQ-405

We changed a bit how parameters are resolved internally in Alpha5, so now they are always resolved by Arquillian and matched against what DataProviders from TestNG produces. But the CDI enricher is a bit greedy and fails if it can't find the Beans, even tho other Enrichers might be able to handle them.

One possible workaround would be to register your DataProviders as CDI Beans instead. Where MyObjectCreator can @Produce MyObject's, that should give you the same effect. Using @Test(dataProvider = Arquillian.ARQUILLIAN_DATA_PROVIDER)  on the @Test method

It 'should' work as before for non CDI deployments.

-aslak-

[bschroeder]

Ok, thanks a lot for the quick answer.

If I am getting that workaround right it's not possible to provide lets say ten Objects representing ten test cases to the same test method, right? Or am I missing something about producer methods here?

[aslak]

hmm, good point.

I think if you create your own DataProvider that returns a Object[n] with the number of invokcations you want, but expose your arguments as CDI Beans, Arq should just resolve the CDI Beans n number of times. And the cdi producer can create new instances pr call.

-aslak-

[daniel_spasojevic]

Hi,

Sorry to post on such an old thread, but my question is related to this behaviour.

It appears that if a TestNG dataprovider provides a value for test that is also injectable by the BeanManager, than the value from  BeanManager will be used in preference. Is it possible to stop the argument merging or the enrichers that are used on a per-test basis?

We are hoping to migrate our home-rolled remote executor for incontainer tests, but changing our dataproviders is not desirable. For all our tests, we would prefer the value from TestNG (whether from a dataprovider or its limited injection support).

We are using:

* shrinkwrap 1.0.0-cr-1

* arquillian 1.0.0.CR7

* jboss AS 7 remote arquillian container 7.1.0CR1b

Thanks,

-Dan

[aslak]

You can stop it pr TestMethod i believe.

Don't annotate the @Test method with the ArquillianDataProvider.

@Test(dataProvider = Arquillian.ARQUILLIAN_DATA_PROVIDER)

[daniel_spasojevic]

Hi Aslak,

Thanks for the quick reply!

We are not using the Arquillian data provider. Despite this, the CDI enricher is still present in the list of enrichers used when merging / enriching the method parameters before the test method is called.

It is possible to trace the parameters through the call-stack. Before the call to CDIInjectionEnricher+resolve(Method), the parameter values are those provided by the DataProvider. Afterwards, they have been set using the enrichers.

Thanks,

-Dan

[aslak]

No, never mind.

As long as any DataProvider is given it will trigger the Arquillian Enrichment of the Method Arguments. And all Enrichers will attemt to lookup all Method Arguments, then all non null values from the Arq Enrichers are copied over the other DataProviders values.  We should probably only overwrite the ones that are null.

Could you create a jira on this ?

[daniel_spasojevic]

Sure.

I think that it is legitimate behaviour for a DataProvider to produce null values for test.

It may be that if TestNG has provided the expected number of parameters then no enriching should happen.

[daniel_spasojevic]

Created: https://issues.jboss.org/browse/ARQ-729

[aslak]

Yea, we need to revisit how this works. Currently the loopup happens before we know if anyone else has provided something.

Thanks for the report

[daniel_spasojevic]

TestNG will fail the test if insufficient parameters are provided / injected with TestNG. I think that this happens before it goes through Arquillian's enrichment process. So I am not sure whether enrichment sense for TestNG tests.

Can you think of anyway to disable the enrichment as a workaround?

Thanks,

-Dan