Arquillian, Drone, PhantomJS are awesome tools to write UI tests but by default scope of PhantomJS is linked to JUnit scope (class or test). When having a big suite it means Drone will fork a bunch of processes and loose a lot of time starting/stopping PhantomJS…for nothing.
Tag Archives: arquillian
Avoid temp session file with Arquillian Drone
By default drone uses a session file. It is by default created in $HOME and it is not always useful. You can override it by a system property but if you don’t want such a file and can’t wait for the fix (should be in Drone 2) then you can write a small Arquillian extension to skip it:
Arquillian and TomEE embedded: multiple webapps, different CDI extensions
TomEE embedded made several progresses recently and it is nice to use with Arquillian. Since it is fully integrated with Arquillian you can deploy 2, 3 or much more webapps in the TomEE embedded instance…but then you have an issue: CDI. CDI extension mecanism is based on Java ServiceLoader mecanism. It means it uses META-INF/services/* to load its extensions. The issue: TomEE embedded is embedded. Of course it shares its container classloader with all applications but in this case you’ll get in 90% of cases your extension as well (cause of Maven, gradle, …). So it means if you deploy your application with the desired CDI extension and another (a test one) where you don’t want them you’ll get trouble since the extension will be loaded.
How to avoid it?
Arquillian, TomEE and big applications: avoid N times the same dump
TomEE arquillian adapters try to make test as isolated as possible but it means if you test a single application in N tests you’ll dump the application N times. For small apps no issue but for big ones it takes time.
To solve it several solutions exist.
Arquillian and TomEE: deploy remotely without hacks!
Arquillian is a great way to deploy an application in a container to test it. However the framework itself doesn’t know if the container is local or remote. TomEE adapter (the bridge between arquillian and tomee) was supporting local deployment but remote one was quite hard and needed to workaround a bit arquillian which was not that fancy.
Since yesterday you can do it easily!
Arquillian Persistence and Embedded container (OpenEJB/DBUnit/HSQLDB case)
Arquillian has a lot of extensions which can dramtically cut needed code. An interesting one is the persistence one which simplifies a lot the DBUnit usage.
The sad part is this extension is designed for not embedded containers….but with this tip you’ll be able to use it (so with OpenEJB, OpenWebBeans, Weld…).
Cuke in Space!, close of a release
Cuke in Space!,  this project aiming to bring cucumber BDD framework to Arquillian. The goal is simple: keep the strength of the Behavior Driven Development adding to it the strength of  Arquillian (portable test writing between containers, deployment control, multi-containers tests…).
Since it is close to a release this post shows important new features you’ll get with it.
What i think about “Arquillian testing guide”
“Arquillian Testing Guide” is a book you can buy on packt publishing website here: Arquillian Testing Guide. I just read it and you’ll find in this article what i liked and what i missed in it.
Arquillian OpenEJB embedded adaptor supports @ArquillianResource URL
Arquillian provides some specific injections. The most known of them is probably:
@ArquillianResource private URL url;
It globally provides you the context url of your web application.
For embedded adapters it doesn’t make a lot of sense to support it (and all your tests are executed “in” the container).
OpenEJB embedded adapter is a bit particular because it doesn’t support a full servlet container features but some part of them only. Its main supported features are (very) basic servlets/listeners, ejbd (remote ejb protocol), JAX-WS and of course JAX-RS.
Cucumber and Arquillian
Cucumber is a nice framework coming from ruby world to do Behavior Driven Development (BDD). It got some nice extensions for others language in cucumber-jvm project.
However it was not integrated with Arquillian so you still had to do all the integration logic yourself.