Testing JSF and RichFaces with Arquillian - Part III - Mastering the Debugger
June 6, 2013
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.
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.
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).
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.).
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.
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.
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.