0

In my production code I have an factory, this factory should be mocked in my test code. I have an interface which both factories implement:

public interface FtpTransferFactory {

    FtpTransfer createFtpTransfer(String host, String machine);

}

Production code:

@Default
public class FtpTransferFactoryImpl implements FtpTransferFactory {

    public FtpTransferFactoryImpl() {
    }

    @Override
    public FtpTransfer createFtpTransfer(final String host, final String machine) {
    return new FtpTransfer(); // Some real ftp transfer object
    }

}

Test code:

@Alternative
public class FtpTransferFactoryTestImpl implements FtpTransferFactory {

    @Override
    public FtpTransfer createFtpTransfer(String host, String machine) {
    return ...; // Some real ftp transfer object, with different settings (test env)
    }

}

In the beans.xml located at src/test/resources:

<alternatives>
    <class>engine.FtpTransferFactoryTestImpl</class>
</alternatives>

My implementing class:

@Default
public class SomeClass
    /** Ftp Factory */
    @Default
    @Inject
    private FtpTransferFactory ftpFactory;

    ...
}

When I execute my unit tests my implementing class still ends up with the production factory instead of the test factory. However, when I put the -element into my src/main/resources (production) it does work. But I don't want that since i'm putting testing code into production code. I've seen several tutorials doing it via this method... what I'm a doing wrong?

Velth
  • 1,108
  • 3
  • 15
  • 29
  • Why dont you use mockito for this kind of testing? – maress Oct 10 '14 at 08:50
  • Because I just want to initialize my "FtpTransfer" object with additional settings (when testing). I want to use the real object, because I don't want to mock it. – Velth Oct 10 '14 at 08:57
  • Do you need runtime information (user input) to create the FtpTranfer instance or are host and machine configurable? If the latter, you can get rid of the factory and use a producer method instead. – Jan Galinski Oct 11 '14 at 11:08
  • 1
    I would argue that using an alternative for this doesn't make sense. If you're reading configuration information that load that in this class and have the method to get a handle a producer method. – John Ament Oct 11 '14 at 23:09

1 Answers1

1

The classes in src/main/resources and src/test/resources are two separate bean deployment archives (BDA). A beans.xml descriptor only affects the current BDA.

So your <alternative> definition only affects your test classes but not your production classes.

If you use CDI 1.1, you can make your alternative global (i.e. activate it for all BDAs in your application) by adding a @Priority annotation.

On CDI 1.0, you could try using @Specializes instead of @Alternative to override your default bean.

Harald Wellmann
  • 12,615
  • 4
  • 41
  • 63
  • If I understand correctly - this means that you can 'never' inject an alternative class into production code? Isn't this one of CDI's goals? However, I was unable to achieve a solution where I'd use alternatives, specializes or priority. I changed my factory to a producer method and all settings are read from the configuration - which is manipulated when running unit tests. Thanks anyway. – Velth Oct 14 '14 at 06:45