Integration testing EJBs with many dependencies in Arquillian

Question

I have often EJBs depending on several (like 5-10) other EJBs/CDI beans and many methods use only a subset of them. Integration testing (we are using Arquillian with the embedded Glassfish 4.0 container) them is painful, because I still have to provide the dependencies for the whole class graph. I add classes one by one to the ShrinkWrap archive, because adding whole packages created even more dependencies and I don't want to add all classes, because it significantly increases the time required to complete one test. I also don't want to have all classes added for every test, especially those touching the file system or executing shell commands.

If the dependency graph grows, I create dummy objects by simply implementing the EJBs interface with methods throwing UnsupportedOperationExceptions, but it is becoming tedious, because there are many of them and it's hard to maintain class name changes (you expect there exists a DummyMyService for MyService, but since it was renamed from OldService you will create another dummy because you haven't found DummyOldService).

Is it possible to automatically create dummy classes (doing nothing or throwing UnsupportedOperationExceptions) for integration tests of EJBs/CDI Beans? Something like:

ShrinkWrap.create(JavaArchive.class, "test.jar")
     .addClass(MyTestedService.class)
     .addClass(ImportantDependency.class)
     .addClass(Dummy.createDummy(DependencyNeededForSomeMethods.class));

for a class like this one when I only want to test the doImportantThings method:

@Stateless
public class MyTestedService {

    @Inject
    private ImportantDependency importantDependency;

    @Inject
    private DependencyNeededForSomeMethods dependencyNeededForSomeMethods;

    public void doImportantThings(){
         ....
         importantDependency.doIt();
         ....
    }

    public void doSomethingElse(){
         ....
         dependencyNeededForSomeMethods.doRarelyNeededThings();
         ....
         importantDependency.doAnotherThing();
    }
}

Or maybe is there another way to deal with it (except for refactoring the classes under test)?

Answer 1

I think, it doesn't provide such feature. Most probably it is a sign of bad design. You should change package structure. And then create wraps only with desired packages.