Earlier this month, Chronon and Bredex announced they would be joining forces to help improve the testing and debugging worlds. Chronon's time travelling debugger, and Bredex's test automation tools are a great combination. I spoke to Prashant Deva from Chronon, and Achim Lorke, CEO of Bredex, to find out more.
DZone: Can you give an overview of what each of the tools does right now?
Prashant: Chronon is a DVR for Java. Chronon records the entire execution of a Java program and allows it to played back anywhere. The replayed program can be analyzed using Chronon's groundbreaking Time Travelling Debugger to quickly identify and solve any problems or bugs that might have occurred in the original program. The Chronon Debugger also contains the 'Post Execution Logging' feature which allows you to add logging anywhere in your code after your program has executed and see the results instantly as if they were already present in the executing program.
Achim: Jubula and GUIdancer are GUI test automation tools. They allow cross platform functional testing for Swing, SWT/RCP/GEF and HTML applications. Their focus is on well-structured, readable tests that can be written by any team member - even (or especially) by people who are not developers. Even though tests are performed through the GUI, the application does not need to be available to write tests. Teams working in agile projects or with continuous integration can benefit from tests being up and running as soon as a new feature is made available. Jubula is an open source project at the Eclipse Foundation and contains the core features to write, execute and analyze tests. GUIdancer is a commercial tool that extends Jubula to add extra benefits such as Code Coverage, Reporting, a Web Dashboard, and Mylyn integration.
DZone: What is the immediate benefit for users of Jubula for this integration?
Prashant: Well so first off, there are 2 different integrations in play here:
First is the integration of Chronon with Jubula AUTs (Application under Test):
This allows users of Jubula to record what happens during their test cases with Chronon. Then if something goes wrong, they can use the recording and play it back in the Chronon Debugger to pinpoint the root cause of the issue:
Second is the 'Embedded Chronon' integration:
This allows users to record what happens in the Jubula environment itself. So if you are using Jubula and you encounter a bug with Jubula itself, you can just click a button to Record jubula, reproduce the bug once, so its captured in the recording, then send the recording to Bredex by attaching it in a bug report on their bug tracker or by other means such as email.
This is really useful, since you no longer have to wait for the Jubula devs to reproduce the bug on their machines before they can fix it. It has happened with me a lot of times when using Eclipse itself, where I constantly run into a bug, but when I report it on the eclipse bugzilla, the eclipse devs cant reproduce it, and it goes unfixed. Even in cases where it does gets fixed there is a whole lot of back and forth on the bug tracker as to how to exactly reproduce a bug, and you have to describe in detail your environment, etc, and it's really time consuming and frustrating for all parties involved.
This solves that problem completely.
Achim: As Prashant said, there is obviously the ease of reporting for Jubula and GUIdancer users through the embedded integration. For users testing their own applications, we think that a great deal of development time can be saved – especially in projects that do have continuous integration. When a test fails from one run to the next, it can only be down to three causes – something changed in the software, something changed in the environment or something changed in the test. The last one is usually easy to rule out. But slight changes in machine performance can mean sporadic racing conditions, and changes to the code can sometimes have unexpected effects. Being able to record what happens in these cases means easier analysis and a quicker fix.
DZone: How difficult was the integration to do? Is it something that all Eclipse projects could easily provide?
Prashant: As for the difficulty, I can't speak for Bredex here, but here is what we have generally observed:
As said before there are 2 different integrations at play here:
The Embedded Chronon is a full fledged product of ours, and we can have you from download to shipping inside your product within an hour.
The second integration is that of the Chronon recorder to record Jubula tests. The integration itself just involves passing a couple extra arguments to the jvm and creating a very small configuration file to go along with it. If you have an eclipse based 'launcher', as in you can right click and do "Run As" > "My App Type", we already have a helper class containing boilerplate code which we can hand you over and the integration can easily be done in just a few hours. In the case of Jubula, it was a little different since they have their own launcher, but the fact that the integration ultimately boils down to just passing a couple extra arguments still made it pretty easy to do.
Achim: Through the integration with JaCoCo in GUIdancer, we already had an extension point for adding monitoring agents. It was pretty easy to add Chronon to the list of supported agents.
DZone: What is the usual response time for Jubula bugs to be addressed? Will this speed the process up?
Prashant: Again I cant speak for Jubula here, but we have seen ourselves when coming across bugs in 3rd party libraries and paying their support staff to fix it, where without Chronon, we got an estimate where just reproducing the bug on the other end would take many, many hours, easily an entire day. Then a few hours more to debug it using the traditional breakpoint based debugger.
With Chronon, we reduced that time to a flat 20 minutes! And no communication was required between our team and theirs, apart from just sharing the recording. We are curious to see how it works out for Jubula.
Achim: For the “easily reproducible” or obvious bugs, I think our times are reasonably good. However, if something is hard to reproduce (descriptions are lacking, it occurs sporadically, or only in a specific user-situation that we don’t have access to) then it can indeed take some time to get to the bottom of it. And if the analysis work itself would take many hours, then sometimes the hard decision has to be made not to look into it right now. That’s always a shame, but a necessary strategy for development. We hope that such situations can be drastically reduced so that we can fix even the trickiest of bugs.