note on the technical part of the request;
BeanTest doesn't seem to do much more then boot up a CDI container and introduce a EntityManagerProducer.
Arquillian does have support for Weld-SE/Weld-EE as a Container which just boots up the CDI BeanContainer so that part is 'done'.
Adding a EntityManagerProducer / TransactionInterceptor to your own test suite should provide the rest.. ?
I think this is a fairly common request as well; something very lightweight, how ever real/fake it might be.
I'd be happy to help guide you in the processes of creating a container like that for Arquillian, Let's call it a non Technology Container, but a Use case container or something..
I think the first step would be to fork the weld-se container, then add some simple mechanics for adding a tiny extension model to create/produce 'non ee' connected versions of ee components (tx, em)
Features covered by BeanTest are:
-producing an injectable @PersistenceContext EntityManger
-enabling transactions ala EJB (rollback if some exception is seen by the interceptor and commit otherwise)
-replacing every @EJB annotation with @Inject thanks to CDI extensions
and not much more. What is still missing is support for resources injected through @Resource and JNDI.
Why do you suggest a fork of the weld-se-container? Wouldn't be enough to write a CDI extension on top of it or do you see limitations in this approach?
Just in general to not change the current one into something else. As we start to see how the weld-se-container needs to change based on this, it might simply end up being as you say a few enabled extensions that could be enabled via a flag in the config..
Ok I'll try this route, though I have to read documentation about Arquillian containers first.
"but become almost useless in large enterprise applications" - The problem with most large enterprise applications is that everything is packed in one big fat EAR file that has to be deployed all at once with fingers crossed. It's an architecture model that almost encourages couplings in your codebase, which makes testing slower and unnecessary difficult.. A component based (or micro service) architecture is beneficial not only from a test perspective but also from a development delivery process perspective. I understand that it might not be possible for everyone to redo their whole enterprise architecture, but I think it's still important to highlight that issue. I've used Arquillian for both component based projects as well as the traditional approach where the whole application resides in one big EAR and the component based architecture is not only more attractive from a test perspective but also makes burdens of development, release and deploy easier.