Added support for running the TCK in Arquillian #84
Conversation
This provides a test class that can be run in Arquillian. I have tested this with Thorntail (using an Arquillian AuxillaryArchiveAppender to add in my own implementation), and it works. I did originally try and make this work better with Arquillian, by trying to have it deploy each test to the container. I was able to work around the fact that the tests are created by a factory by writing my own custom container test runner that gets them from the factory. I was able to work around the fact that none of the tests extend the TestNG Arquillian by extracting all its logic into a TestNG listener that was applied to the whole suite. And finally, I was able to work around the fact that none of the test classes has an @deployment annotated method on it, by writing a custom DeploymentScenarioGenerator that extracted the deployment from a different class - the same class for each test. This was the most annoying one because WildFly has its own custom one, so doing this in a generic way was impossible. So, in the end it worked, however, it was a lot of what felt like very fragile code, so my strategy in the end was simply to write one Arquillian test that has one test method, and then, in that test method, instantiate a TestNG runner that runs the entire suite for me, using a CDI injected ReactiveStreamsEngine. If you run this from the IDE, it says there's only one test, but the logging shows 1100 or so tests, and makes it clear which failed and what the failures are. Also fixed two bugs in the TCK where the default engine was loaded instead of the passed in one.
|
@lordofthejars can you have a look to be sure it follows the recommendations? @jroper the strategy looks good to me, but I don't understand how to run it. Adding a README would be very beneficial. I only used Arquillian with Junit so far. |
|
It should be a matter of running the |
|
@cescoffier Here's an example of using it. If you're testing against a container that has an implementation of mp rs ops built in, then you shouldn't need any of the Arquillian extension code, that's just to add an implementation to the container. |
|
Documentation added in #85. |
|
@jroper got it to work. I needed to add a producer creating the engine instance. The producer had to be in a specific package. |
|
Merging as it was decided in the weekly hangout that this is the right approach. |
|
Sorry for being late, I will do tomorrow, we can always improve in another
PR
El mar., 7 ago. 2018 21:07, James Roper <[email protected]> escribió:
… Merging as it was decided in the weekly hangout that this is the right
approach.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#84 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABcmYVGzuEDJrD3KsFfVuWLmmHipb3gXks5uOeVcgaJpZM4Vrt6N>
.
|
|
@lordofthejars No worries. Just so we're clear - there are two different TCKs in MicroProfile Reactive, one for the streams spec, that's this one, and one for the messaging spec, that's the one where we've done the most work with Arquillian and talked about in previous hangouts. The streams spec has no dependence on CDI or a container (and we hope to make it part of the JDK one day), it's just a stand alone library, hence, it doesn't need (and shouldn't require) Arquillian to run. So it provides about a hundred test classes that don't and can't have, for example, Arquillian deployment annotations on them. That said, some vendors are going to want to run this TCK against their container. So, this PR introduces a new artifact that can run the existing TCK in a container using Aqruillian. See the original description on this PR for my attempts to do this in a more idiomatic Arquillian way defining extensions to dynamically add deployments to test classes that didn't use an Arquillian runner etc, I got it working but it felt too complex and hacky. |
This provides a test class that can be run in Arquillian. I have tested this with Thorntail (using an Arquillian
AuxillaryArchiveAppenderto add in my own implementation), and it works.I did originally try and make this work better with Arquillian, by trying to have it deploy each test to the container. I was able to work around the fact that the tests are created by a factory by writing my own custom container
TestRunnerthat gets them from the factory. I was able to work around the fact that none of the tests extend the TestNGArquillianclass by extracting all its logic into a TestNG listener that was applied to the whole suite. And finally, I was able to work around the fact that none of the test classes has an@Deploymentannotated method on it, by writing a customDeploymentScenarioGeneratorthat extracted the deployment from a different class - the same class for each test. This was the most annoying one because WildFly has its own custom one, so doing this in a generic way was impossible. So, in the end it worked, however, it was a lot of what felt like very fragile code, so my strategy in the end was simply to write one Arquillian test that has one test method, and then, in that test method, instantiate a TestNG runner that runs the entire suite for me, using a CDI injectedReactiveStreamsEngine. If you run this from the IDE, it says there's only one test, but the logging shows 1100 or so tests, and makes it clear which failed and what the failures are.Also fixed two bugs in the TCK where the default engine was loaded instead of the passed in one.