1 of 1 people found this helpful
- How to test xml validation? It seems that to test validation one needs to call an InboundHandler that will trigger the execution of validations defined in an xml file, so they can only be tested in a running container. Maybe using HttpMixIn to trigger the invocation, or any other way, but in a "real" "running" container.
- How to test JAXB transformations? These tests also seem to need a "running container" so composites need also to be deployed as in the previous example.
Transformer can be triggered even in the unit test. Validator does as well. You may want to take a look at transform-json. JsonTransformationTest expects JSON transformer being triggered while it invokes the service via test Invoker.
- How to test binding configurations? If I set up a specific message composer or message context, or even jax-ws security configuration, these tests also need to be run against a "running container" so composites need also to be deployed as in the previous example.
For example, when you want to test SOAP inbound, you can just send a SOAP message in the unit test case, and use MockHandler to verify the input message. WebServiceTest in the bean-service quickstart demonstrates invoking SOAP inbound in the unit test using HttpMixIn.
- Can I create a UserTransaction and use it when calling a testKit's ExchangeHandler or MockHandler? If so, how? We have a service, where we call an EJB and we have 2 problems here, first one is regarding injection of PersistenceContext, that it doesn't get injected into the EJB (or at least CDIMixin doesn't do it) and the other problem is that there is no transaction. Probably this one is related to persistence.xml configuration that is used.
TransactionMixIn does that. You should be able to lookup UserTransaction once you add the TransactionMixIn to the mixins list. camel-jpa-binding quickstart is using JTA type of persistence.xml, the testcase doesn't touch UserTransaction though. PersistenceContext injection doesn't happen in the unit test. It needs JavaEE environment.
Thanks for your clarifications, and now 2 more questions:
- HttpMixin uses an HTTP endpooint, so 1) where is the port coming from? 2) Is SwitchYardRunner running an embedded http container (or what) in that port?
- You said "PersistenceContext injection doesn't happen in the unit test. It needs JavaEE environment.", but why? If I have a CDIBean (my own bean) registered as a PersistenceContext before deployment, shouldn't CDI MixIn inject it?
Follow-up to Tomo's final point : if you are testing EJBs, you're better off using Arquillian with a remote container. Everything else you described can be done with SY unit test framework.
Strictly speaking, SOAP binding starts embedded endpoint by default. The port number is configured by socketAddr property in the binding.soap. JBossWS integration happens only when it's detected. @PersistenceContext injection is not a simple CDI injection. It needs JavaEE container support to manage the lifecycle of EntityManager.
I have a wsdl with Policies, and it seems that in junit, policies for the embedded server are not taken from the composite, and I can also not alter the interceptor chain, as this also does not work. I have verified that the policies that I set in the composite doesn't get applied. I know there is a JIRA opened for this, and solved for 2.0
Any way to circumvent this situation? Only way I have seen, for now is to clone the wsdl for tests and remove the policy.
As Keith mentioned, even for policies, you will need Arquillian with a remote container to test it. Else you can create simple clients to test against a container as it is done in the quckstarts. Please see quickstarts/demos/policy* for more details.