We have previously discussed which technologies to use and how to improve the test development turnaround when we want to test JSF with Arquillian.

However developing tests using the right tools used the right way isn’t the last stop in a development cycle. However by improving our tooling and speeding up our development cycle we cover just a half of efforts we put into test suites.

The another big portion we spent with is test maintanance. Your tests will very likely hit issues which you will need to analyze sooner than later.

And that’s where Arquillian strikes again – it not only helps you to discover a bug, it will also help you to debug it and find the root cause.

Debugging

With an automated test scenario in form of Arquillian test, you are getting the ultimate tool for reproduction of an issue in your hands.

You can repeatedly run the test, and always as you hit an issue, you are also provided with the context which led you to the failure.

So let’s stop refreshing a browser window in order to see an issue – write a reproduction scenario and open the tool, which will give you immense power during test maintanance – the debugger.

Server Debugging

When you started an application server in debug mode, the only step left is attaching your IDE to a remote JDI session.

In order to debug all the context, it is useful to attach the sources of an application server (that is another case where open source projects shines).

Browser Debugging

The opposite end of your application usually comes a little wild – a web client. In order to tame this beast, you will need to master an altogether different sort of tool: browser development tools.

Each of the mainstream browsers comes with such tools:

• Chrome DevTools
• Firefox Developer Tools (alternatively Firebug)
• Opera Dragonfly
• Internet Explorer DevTools

The fact that by using Selenium you control a real browser will help you to hit same issues you are running into during test execution.

Reusable Debugging Session

Do you remember I told you to use a remote reusable session? It is not just for the sake of saving browser startup time.

When Drone’s reusable remote session feature is enabled, the browser session remains open until you kill it. As oppose to a standard Selenium mode which starts and stops the browser for each test case, you can recycle the browser session setup – including the setup of the developer tools (opened tabs, breakpoints, etc.).

Warp

The Warp extension opens completely another set of options – it is a tool for programatic inspection of a server-side application logic while test is executed from the perspective of the client. And it plays really nice with a browser-based tests.

Warp can be used to narrow down an issue. Do you have an assumption that something is going wrong on the server? Just describe your expectations in your test code as assertion. Do you want to debug some code which is hardly accessible – let’s hook into the execution and see what happens.

Debugging Arquillian

I can guarantee that sometimes the Arquillian tests will fail to do what you want.

No matter whether you are hitting an Arquillian’s issue or your own issue, it always helps to see what actually Arquillian do and compare it with your assumptions. Revealing a test execution internals can sometimes avoid a lot of time debugging issues caused by badly written test.

Conclusion

As you can see, Arquillian empowers you not only with new options of how to write reliable tests in very lean fashion, but also the infinite power of debugging application on both, server-side and client-side.

So, stop mocking the tests, when you can use real tests that gives you outstanding insight nothing can surpass.

Next Time

In the next part of this series, I will explain how we achieved automation – and as I already announced, we won’t stay just with simple test execution.