Playing With Arquillian Results
andygibson Sep 9, 2010 4:41 PMI've been having a play with Arquillian for the last few days and thought I'd report back. I might have found some issues but I don't know how many are user error. Example configuration was pretty much taken from the docs.
- Getting build versions that work together correctly is a bit of a hurdle - doubly so when you aren't sure if everything is configured right in the first place.
- Getting the maven dependencies right can be a problem. The scaterring of Java EE 6 poms makes it a rather hodge podge affair since the java-ee bom seems to incompatible with Arquillian. I usually have to add the server runtime in eclipse to help out in the IDE. (This in turn causes odd errors in the eclipse plugins about being able to launch javaw.exe when I try and run the tests)
- So far I have only got Glassfish and JBoss embedded working fully with a database and running tests within CDI conversations.
For JBoss Remote/Managed and Glassfish remote, I get the same error (so I wonder if it is a setup issue). I use the same conversation context management technique defined in http://ctpjava.blogspot.com/2010/08/test-drive-with-arquillian-and-cdi-part.html .Basically, using a junit @Rule to start and end the conversation if needed. The conversation context creating code is also used in Seam 3 in a few places.
When I try to fetch the conversation context like so :
{code}conversationContext = Container.instance().services().get(ContextLifecycle.class).getConversationContext();{code}
I get a "Singleton is not set" error in the call to Container.instance() which in turn calls instance.get(). If I have a test that doesn't start/end the conversation and just uses request scoped CDI injection then everything is fine. Interestingly, now I'm starting to get it on the Glassfish embedded tests as well. It will probably go away if I twiddle with things enough.
I do have a stand alone project to demonstrate this stuff if you think it is more than a config issue.
Indcidentally, I think the first instinct is to go and try an embedded server for that "one click and you're running" isolated feel, however, it is slow and you lose that "one click and you're done" feel. I started with the embedded version but I would much rather have my remote server working because it is just much faster. While Glassfish typically starts in a second, the embdded server takes longer. It's almost like waiting for development server re-start (which is what it is really!), which is why I think remote testing will be more popular.
Overall though, I love it, I think with this and JSFUnit you can have end to end testing of your java EE apps. Imagine being able to get a bug report and reproducing the whole thing in a test case (JSF presentation layer and all). Awesome.
Cheers,
Andy Gibson