Unit testing a CDI SPI with JUnit

[bert-laverman]

I have a Maven project with (basically) two modules:

• The first module is the CDI SPI.
• The second module is a Java/Jakarta EE app to demo the SPI.

I tried adding Unit tests to the SPI module using JUnit 4, weld-junit4, and Weld SE. The build works, but the unit tests fail because the SPI appears not to have loaded. I have lots of logging in it, so would definitely see it coming by.

Can anyone tell me how to Unit test a SPI with Weld-SE?

Cheers,

Bert Laverman

[manovotn]

Hello,

I am afraid I do not understand your question.

Do you have some code sample to share? Or better still, a project to show? What errors are you seeing?

Speaking very broadly, if you are aiming at unit testing with CDI SE container, then weld-junit is indeed a good entry point. Note that in this case you are mostly composing an "artificial" (synthetic) archive and have to make sure all the necessary classes are known to Weld container.

If it's more of an integration test executed on a full-blown EE container, then Arquillian is a great tool.

EDIT: If by CDI SPI module you mean CDI extension, than note that in default Weld SE settings, you need to register any extensions as discovery is turned off.

You can do so through this method while creating the Weld object (which you then pass into Weld-junit).

[bert-laverman]

Matej,

thank you for your reply. I guess your final remark is what I am after. when I use:

@Rule public WeldInitiator weld = WeldInitiator.of(WeldInitiator.createWeld().addExtension(new AxonCdiExtension()).addPackage(true, AutoWiredEventSourcedAggregateTest.class));

Everything starts up. Of course I still get errors, but those are the ones I knew needed fixing. :-) And testing with JUnit this way its way more efficient than trying to debug a running JEE server.

Cheers,

Bert

[bert-laverman]

BTW I realised I made a mistake in that line. It should be:

    @Rule     public WeldInitiator weld = WeldInitiator             .from(WeldInitiator.createWeld().enableDiscovery().addExtension(new AxonCdiExtension()))             .inject(this)             .build();

This works perfectly.

Cheers,

Bert

[manovotn]

I think you might be mixing it up now.

If you enableDiscovery() you have Weld do what it does usually in EE environments - scan the classpath . This is something you often want to avoid for SE and for unit testing. Hence by default Weld doesn't do that.

One of the effects of discovery is that CDI extensions are discovered as well (service loader mechanism kicks in) which means that while using enableDiscovery(), you shouldn't even need addExtension() call.

I think you might be mixing it up now.

If you enableDiscovery() you have Weld do what it (approximately) does in EE environments - scan the classpath . This is something you often want to avoid for SE and for unit testing. Hence by default Weld SE doesn't do that and instead let's you cobble together a minimal synthetic archive.

One of the effects of discovery is that CDI extensions are discovered as well (service loader mechanism kicks in) which means that while using enableDiscovery(), you shouldn't even need addExtension() call.

[bert-laverman]

Yep, enableDiscovery() allows me to remove the addExtension() call. Unfortunately, the other way around I run into trouble. I tried addPackages(true, Package.getpackage("org.axonframework.cdi")) and addPackages(true, AxonCdiExtension.class). The first gives a nullPointerException, the second unsatisfied beans. The only way I can riddle the second is that it needs to scan all classes of the Bean's types? AxonCdiExtension is at the root of the project's sourcetree including all test code, but it refers to other JARs with the Axon Framework code. I've never used Package.getPackage(), so I haven't a clue why it would return null. (sorry; I'm a user of Weld, not a developer.)

Cheers,

Bert

[manovotn]

The addPackages() method is most commonly used with Class as a parameter. From class Weld then derives the package and adds everything from that package (with the option of recursive addition).

NPE is possibly because Package.getPackage() method can return null if it doesn't find anything (and we might be missing null check there?).

Unsatisfied dependency means that classes you added so far are not enough to cover the dependencies you want to inject. Therefore, some are missing - you probably didn't add some different package or class with given bean.

Other option is that if you mean to add whole JARs (libraries like DeltaSpike etc) then you will indeed need a discovery for Weld SE doesn't allow that but that.

I would need to see the code and exceptions to be able to navigate you any further.

[bert-laverman]

I was experimenting locally. Will add the files to a new branch in the public repo for Axon Framework CDI module. (GitHub - AxonFramework/cdi: Axon Framework CDI Support )