The MicroProfileConfig TCK has a test that expects to get a DeploymentException when a deployment can not be properly deployed[1]:

@ShouldThrowException(DeploymentException.class)
    @Deployment
    public static WebArchive deploy() {
        ...
    }

The test passes fine when org.jboss.arquillian.container:arquillian-weld-embedded is used but when in WildFly when org.wildfly.arquillian:wildfly-arquillian-container-managed is used.

After some investigation, the issue seems to be located in https://github.com/wildfly/wildfly-arquillian/blob/10eaa4aedee17e887b267f4fa858a5d5e59b768d/common/src/main/java/org/jboss/as/arquillian/container/ArchiveDeployer.java#L173, the deploy result is a failure due to an actual DeploymentException on the server side.

However the method will create a new DeploymentException with a message but without a cause. At this point, this new DeploymentException is not linked to the server DeploymentException.

When the @ShouldThrowException is checked, Arquillian will call DeploymentExceptionHandler#transform to get the actual cause of the exception[2].

The exception is an instance of DeploymentException but its cause is null.
=> the method returns null and the @ShouldThrowException check fails.

To be correct, the code should somehow infer the exception that causes the issue on the server side and recreates it on the Arquillian client side to use it as the cause of the DeploymentException.

My test is expecting a DeploymentException but other user reported the same kind of issue in WFARQ-36 with another DefinitionException.

[1] https://github.com/eclipse/microprofile-config/blob/1519484a82d907969bf5a66795d86e6a994a21db/tck/src/main/java/org/eclipse/microprofile/config/tck/broken/MissingConverterOnInstanceInjectionTest.java#L41
[2] https://github.com/arquillian/arquillian-core/blob/8fd124fc0a8581d475f53f5f0769b110065b5c2f/container/impl-base/src/main/java/org/jboss/arquillian/container/impl/client/container/DeploymentExceptionHandler.java#L104