It is practically unavoidable to hit issues during a test execution. Fortunately, with the Arquillian, debugging such issue is a really simple task.

Revealing Arquillian Internals

Curious what might happen as the test fails?

Let’s look at a following snippet of a Arquillian execution log:

For a sake of simplification, I have removed some unimportant parts.
(E) ManagerProcessing
	(O) LoadableExtensionLoader.load
	(E) ServiceLoader
(E) ManagerStarted
(E) BeforeSuite
(E) BeforeClass
	(E) DroneConfigured
		(O) DroneCreator.createWebTestBrowser
PhantomJS is launching GhostDriver...
		(E) DroneReady
(E) Before
(E) Test
	(E) ExecutionEvent
		(O) LocalTestExecuter.execute
(E) FilterResponse
		(E) ExecuteWarp
(E) FilterRequest
	(O) EnrichmentObserver.tryEnrichRequest
        (R) /ITTableState/faces/index.xhtml;jsessionid=v97p4MziZB0-9ymGaHHuQqcW
	(E) EnrichRequest
		(O) EnrichmentObserver.enrichRequest
                (W) /ITTableState/faces/index.xhtml;jsessionid=v97p4MziZB0-9ymGaHHuQqcW
(E) FilterResponse
	(E) DeenrichResponse
(E) After
(E) AfterSuite
(E) ManagerStopping

Arquillian Core is de facto an extensible event machine based on a network of loosely coupled components – services – which are triggered by events and their observers.

Arquillian can print a nice overview (in a form of event tree) revealing how events flows through a system while running a test.


In order to

[E] observable event
  - an event was fired
  - or object was produced to the context
  - or exception happened in an observer
[O] observer - the event was observed by a observer
[I] interceptor - the event was intercepted

If you compare the event tree on the start of this blog, you can now identify that the tree contains an information how events are fired ([E]), what observers reacts on them ([O]) and what interceptors are used during an observing ([I]).

Additionally some extensions like Warp can add some own information:

[R] the request was noticed on a proxy
[W] the request was inspected by Warp

Turning Debugging Mode On

You can turn the debugging mode by using the VM argument (both, for the test and for the application server):


Debugging in JBoss Developer Studio

IDEs usually does pretty good job and allows you to configure VM arguments as needed.

Eclipse specifically has little drawback – the configuration of VM arguments is set on a level of test configuration.

If you are using JBoss Developer Studio 7+, you are lucky man – it allows you to configure VM arguments for all executed application servers and JUnit/TestNG tests.

blog comments powered by Disqus