Arquillian Testing Guide
Buy it now
One Minute Bottom Line
|A nice book for a company and beginners.|
First the progression of the book is globally:
- A presentation of Arquillian
- What was done before Arquillian and why it answers to needs of today
- Arquillian and containers
- “Common” pitfalls you can fight with
- Arquillian enrichers
- Arquillian extensions
- Functional testing with Arquillian
- Service testing (SOAP, REST webservices, JMS etc…)
- OSGi case
More details on the parts can be found on the pack publishing website (http://www.packtpub.com/arquillian-testing-guide/book#overview).
First what was kind of shocking for me was the fact to deal with ShrinkWrap at the end. Ok you can go with Arquillian without ShrinkWrap but it is not natural at all for me. It is not blocking in the book but surprising and reading it linearly you can sometimes think “yes, but if i want to…”.
I wonder too if both first parts shouldn’t be reversed but it basically does the job explaining what is Arquillian and why it is better than what we were (or not doing before.
That’s all for the order of the parts .
Starting the book i really liked that the author (John D. Ament) targets today enterprise tools: Maven, Weld/OpenWebBeans/TomEE/JBoss AS, CDI, SoapUI, Selenium…it really answers to the everyday life of a Java (EE) programmer.
The book contains lots of advices, “good practices” on testing which is nice but a bit disappointing if you expected a book going really deep in Arquillian.
The container chapter has the advantage to present you most of the existing adapters but not all and a bit disappointing the configuration of each adapter is not complete at all and i doubt it is enough when you are writing real tests (more on it in my comment on the TomEE/OpenEJB adatpers).
The part on common pitfalls is interesting even if some of them can be missing (the one on the surefire minimum version for instance). It is great to read it to get some idea of the issue cause when you feel naked facing an error.
The enricher part explains what you can do as a user without going deep in details. Don’t expect to write yourself enrichers after this part but you’ll be able to use it and get CDI/EJB/…in your test.
The extension part is about some existing extensions. Here again don’t expect to be able to write a real extension with this part but you’ll know how to go further and even how to get some quality figures of your tests with Jacoco. In this part i really loved the spock part showing Arquillian is not limited to Java and open to other way of testing than JUnit (i really invite you to test it).
The functional part is really interesting because it deals with Warp which is really the killing feature of Arquillian in my opinion (testing client and server sides in a single test). There is even a sample using Spring MVC! Some advanced features available today are missing but the book was written just before it was released so that’s normal and not blocking at all to get started.
Service testing (with SoapUI for instance) and OSGi parts match their titles but i’m not sure it would be useful out of the box. I really doubt of OSGi case since Pax Exam seems still more appropriated since very deeply integrated with OSGi world (but that’s just my feeling).
Finally ShrinkWrap part! The part is very short (of course some advices was given before since it was needed in previous parts . I think a table explaining the available API out of the box is missing. You need to go through the part to find the information but once you read it you know how to describe your archive and use it in Arquillian. Personally this part is more interesting for beginners than advanced users which will use their IDE to learn ShrinkWrap. Some semantic could have been explained a bit more but i think it is enough to make you starting an IDE and try it out.
My conclusion on the book
As a framework/library writer or a technical guy you’ll probably be disappointed since you’ll not go into the details of Arquillian (the explained lifecycle induced by Arquillian is good to get an overview but not real depending on your case, arquillian.debug was not mentionned…). I was really disappointed to not get any part on writing custom arquillian extensions, archive processors, observers…
As a simple user you’ll get a great overview of the product (even if you’ll still need to do it yourself to get convinced . This book deals with main concepts and explains what was done before and why Arquillian is nice today (this part is important for your boss for instance .
So in a single sentence i’d say all enterprise teams will need to get this book in their shelf to allow new programmers to get started or to keep pointers on basic concepts but it will not prevent you to google and try it out when needing to go further.
A word on TomEE/OpenEJB case
Of course the book deals with adapters. In them you’ll find TomEE of course and OpenEJB one…version 3.1. I was sad of it. OpenEJB 4 adapter is really great and can’t be compared to OpenEJB 3 one. With the 4 you can even test webservices, some basic servlet etc…
Now about TomEE: as for other adapters the configuration available is far to be detailed. Of course for TomEE (which is probably the most configurable adapter) it is not that easy to get enough space but it is sad to read things like “you need to use system properties” – it is just an override mechanism, not the adviced one.
Another sad thing (but that’s true in global arquillian realm): tomee + openejb adapters can be both used without any maven profile, you can easily split your tests in openejb embedded/tomee embedded/remote tomee categories without any maven profile! That’s a TomEE/OpenEJB feature but it is interesting to see you can get a (consistent) build without needing to use maven invoker plugin or to split your tests over submodules or (worse) run your tests several times.
Of course you understood i was disappointed of OpenEJB/TomEE adapters explanations but how could it have been different since i contributed a lot in their code and the book was too short to go deep in the details
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)