This year at Eclipse Con Europe, members of the Jubula / GUIdancer team from BREDEX attended the conference to speak about testing and continuous integration as well as to meet our users and share experiences working in Eclipse. Here’s some of our impressions…

Over the past few weeks, we've been working on updating the "Services" section of the BREDEX website. We're pleased to announce that the new content is now online, including descriptions of what we have to offer as well as examples of projects we've carried out / are working on at the moment.

On 5th September in Darmstadt, the third Eclipse Testing Day will open its doors. This year, the program committee has put together a new format that includes standard talks about testing and Eclipse, lightning talks about areas "beyond testing" and a whole new interactive panel discussion.

Retrospectives are great. Not just because of the chance to talk about current process, problems and improvement, but also because they can give you some insight into how much things have improved.

It’s out! After many months of hard work, some occasional head-scratching and a great deal of fun with the e4 platform, we’re pleased to announce that Jubula is a part of the Eclipse release train for the second year running.

One of the things missing in older Jubula and GUIdancer versions is a possibility to work with equivalence partitioning to avoid redundant data. Since the release of Jubula 1.2 and GUIdancer 6.0, it is now possible to use functions as test data and add your own functions to link exactly the data you need.

"I love deadlines. I like the whooshing sound they make as they fly by."

I won't say who I most recently heard this quote from, but let's just say that we've decided to give you an extra week to enter your talks for the Eclipse Testing Day. We've already received some excellent submissions, but due to popular demand, we're extending the deadline until Friday 8th June.

It only seems like yesterday that EclipseCon was beginning, and now Demo Camp season is almost upon us! And shortly after Demo Camp season it will be time for the Eclipse Testing Day 2012! So get your diaries out and start marking some dates...

Just in time for EclipseCon 2012, the Jubula/GUIdancer Team has released the new standalone versions of both tools. The spectrum of new possibilities is particularly nice for this release, I think, so I'm going to take you on a tour of the new features.

We're really pleased to be able to announce a Jubula Training Day on 3rd May in Florence, Italy in collaboration with RCP Vision and their Eclipse Day Florence (4th May 2012).

Recently, I wrote a first blog entry in a new series of “automated testing topics” on using BIRT reports in GUIdancer. In this entry I’m going to continue, as promised, with the sometimes rather tricky aspect of code coverage.

Background

Back in early 2011, when we were deciding where and how to split GUIdancer into two tools, we put a lot of consideration into what we wanted to achieve with our Open Source activities. We firmly decided that Jubula users should have all they need to write, execute and analyze tests. We wanted to have a good, well-rounded tool as our Open Source contribution, not something that is missing necessary features. Nevertheless, we did want to save some nice features for GUIdancer, the idea being that for a small amount of money, you can add some nice aspects to your testing project and process.

As it turns out, many of the features we kept closed source and as part of the commercial tool are things that are likely to become nice-to-haves once you’ve got more than just a few tests up and running. Once tests start getting bigger, then aspects like Test Style (like Checkstyle) and Mylyn integration really start getting interesting. And if you’re using Jubula in CI processes and your tests are gaining in importance, then it would be nice to have reporting capabilities (you know, for the managers ;) ) and to get some information on code coverage. If you’ve already used Jubula successfully in one project, then maybe you’ll think about starting testing even earlier next time with the Model-Based approach.

But these are things that come later, and we often get asked the question by newer users – what can I do with all of this? Well, in a short blog series, we’re going to describe how the various aspects of GUIdancer are designed to be used, and how they help us with our work in the Jubula project and in customer projects. This first entry will look at how we use BIRT reports in our daily, weekly and monthly work.

GUIdancer and BIRT – the basics

Jubula contains various options to analyze single test runs – a test result report appears dynamically during test execution, and individual test reports can be reopened including information on error-types and screenshots. This is indispensable in a test tool – I need to be able to see what went wrong so it can be fixed. However, what this doesn’t allow me is any kind of view over time. Questions such as:

• How many tests ran successfully / failed / didn’t run this week / month?

• How many tests have been added over the last period of time?

• How has the code coverage developed since adding the new tests?

can’t be answered with single test runs; they need to be cumulated and displayed in an easily readable manner. This is the aim of the BIRT integration in GUIdancer.