RSS Feed for the BlogEclipse 4 Training Day following the Eclipse Demo Camp Braunschweig
24.04.2012 16:54 by Alexandra Schladebeck
Anyone thinking of coming to the Braunschweig Eclipse Demo Camp on 28th June should think about extending their stay in Braunschweig for the following day as well. We're pleased to welcome Kai Tödter from Siemens AG to BREDEX to hold a one-day training course on Eclipse 4.2 applications.
Two days of Eclipse
Day one, Demo Camp
At 5pm on the 28th June, BREDEX is organizing a demo camp in Braunschweig. Confirmed presenters include Kai Tödter, Ed Merks and Marcel Bruch - and we're working on a couple more 
BREDEX will also be doing a demonstration of Jubula. Registration is now open via the Eventbrite site - so sign up for a great evening!
Day two, Eclipse 4.2 Training
The following day (29th June), Kai Tödter is holding a one-day training course on Rich Client Development with Eclipse 4.2. This is an excellent opportunity to get up to speed on the latest developments in Eclipse without having to travel to far-off conferences or workshops. A full description of the training day is on the BREDEX website, including a link to the registration. Places are limited, so register early.
Upcoming Eclipse Events - Demo Camp and Testing Day
18.04.2012 14:28 by Alexandra Schladebeck
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...
Eclipse Demo Camp Braunschweig
On 28th June, there will be a Demo Camp in Braunschweig starting at 5pm. The Eclipse Wiki page gives more information on the event, including a link to the registration page and the opportunity to sign up as a presenter. There are still some spaces left, so come and show us what you're doing with Eclipse!
Eclipse Testing Day
The third Eclipse Testing Day will be held on the 5th September 2012 in Darmstadt. The call for papers has started; please send your submissions by the 31st May 2012.
We're also pleased to announce our current sponsors: GFB Softwareentwicklungsgesellschaft mbH, Diaz & Hilterscheid GmbH, and Verit Informationssysteme GmbH. We are also collaborating with Professional Tester Magazine and Testing Experience Magazine. There are still sponsoring positions available, and of course we're looking forward to hearing about the Eclipse community's experiences and adventures in testing as well as meeting testers, developers and project managers on the day.
Call for Papers for the Eclipse Testing Day is open!
13.04.2012 09:21 by Alexandra Schladebeck
Do you have an Eclipse-related testing story to tell the community? Then enter a submission for the Eclipse Testing Day 2012 (5th September, Darmstadt)! You can enter your abstracts until 31st May and the program committee will announce their decisions in June.
What we're looking for
The topic for this year's testing day is "Testing and Beyond". The program committee are putting together a format that will consist of traditional talks on the topics below, as well as a set of lightning talks from areas "beyond" testing and a panel discussion with experts from the Eclipse and testing communities.
The topics for talks could be:
- Testing Eclipse applications
- Testing within the Eclipse Ecosystem
- Testing on Eclipse Projects
- Design for testability in Eclipse
- Case studies of testing projects
- Eclipse tooling and technology for the test process
- Continuous integration and testing for Eclipse applications
As in the past years, demonstrations and case studies are very much welcome but product demonstrations will not be accepted. Submit your abstract (in English, 100-200 words) and your biography to testingday at bredex dot de by 31st May 2012. More information on talk submissions and length is on the wiki.
Be a sponsor!
The Eclipse Testing Day is a not-for-profit event. Costs are primarily covered by the organisors and our sponsors. We have a range of sponsoring opportunities available - sign up to support this great event and meet Eclipse users and testers on the day.
Come to the event
The registration will open shortly after announcing the program. If you would like to be notified when registraion opens, then send an email to testingday at bredex dot de.
We look forward to an exciting event!
What's new in Jubula 1.2 and GUIdancer 6.0
19.03.2012 11:23 by Alexandra Schladebeck
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.
Test result reporting
We've had the Reporting Perspective for some time now, and it's one of my favourite additions over the last few years. In almost every team I've been a part of, it takes time to learn how to deal with test results and to define how to react to them as a part of the process. That's one of the reasons why we keep adding new features to this area - that and the fact that we also use the reporting capabilities on a daily basis. So what's new this time?
Web dashboard
An added feature in GUIdancer from 6.0 is that we've made the reporting perspective available in the browser thanks to the magic of RAP. Now you can do your test result analysis from the browser - which is excellent if you're not at your desktop, or if you 'just' want to perform analysis and don't need an installed GUIdancer.
More test result details
One of the new features available in both Jubula and GUIdancer is more information in the test result reports. We've added the cumulative duration to each node in the result report as well as the data used for the node. Instead of having to expand the test result to see these details, they are instantly visible at each level, so now you can easily see how long each part of a test is taking as well as which data sets were used.
Create Mylyn task
As an extension to the Mylyn integration in GUIdancer, we now also have the opportunity to create a task in external systems (like Trac or Bugzilla for example) directly from a Test Result Report. So if you open up your test result and find that the Test Suite failed due to an error in the software, then you can create a ticket for it directly from GUIdancer.
Working with test data
Alongside the extras in test reporting, we've also made some improvements to actually writing tests. One of the directions we've gone in is test data.
Functions
One of the aspects of test data that has been missing for a while is being able to use functions. Well, those days are over. Jubula 1.2 and GUIdancer 6.0 both support the use of functions as test data. There are a few basic math functions (add, subtract, multiply, delete, round and truncate) and some date functions (now, formatDate, modifyDate and parseDate) that we've already written, but new functions can be added via an extension point as well.
In-editor decoration for missing data
Often its the small things that really make a difference. We've added decoration within editors to show you if you've forgotten to enter data. No more saving and then realising that you've forgotten something - now you can see instantly whether the data in the editor you're working on is complete or not.
Other really cool stuff
So we've got some exciting things that fit into the areas of result reporting and data. We didn't stop there though, there's more cool stuff in other areas as well:
Metrics framework
In both Jubula and GUIdancer, there's now a new framework for Metrics within the project. We've added three example metrics to it at the moment, and we'll be expanding the possibilities in later versions. At the moment though, you can already
- count various things (Test Cases, Event Handlers, Test Steps etc) in the project,
- calculate the ratio of specific actions and general actions used throughout the test,
- and show any redundant-looking hierarchies that you have created
Categories in the Test Suite Browser and Central Data Sets Editor
The Test Suite Browser and Central Data Sets editor just got prettier: now you can categorise your Test Suites and Test Jobs as well as any central data you have in your project.
New action: store property value
Sometimes you don't know how many rows you have in a table, but you do know that after searching it should be less than before. A new action to store the property value lets you do this. Combine it with the "check string values" or "check numerical values" actions to perform the checks you need.
Save As New Test Case
I've deliberately left this until last because it's both exciting and terrifying. Since its conception, GUIdancer (and now Jubula) have been staunch opposers of copying and pasting. We've always said - if you need something twice you should make a module and reuse it. And we still say that. But based on some talks with customers, and some enhancement requests and forum entries, we've relented just a little bit for a specific use case.
Imagine you have a wonderfully structured, modular test. It's perfect as it is, nobody could accuse you of being lazy with your modularisation. Nevertheless, you need other use cases that consist of variations of the modules you have in this test. For one use case, you need them all with an extra one in-between. For another you need most of them but not the last one, and so on. In this case, you'll be thankful for the new option "Save As New Test Case". You can use it to create a new Test Case that already contains the modules you select from an existing one and so save time looking for the same modules again.
Sounds great, where can I get it?
GUIdancer 6.0 is available from the BREDEX GUIdancer page. Jubula 1.2 is available from the Eclipse Project Page. Bear in mind that the new version of Jubula is just the standalone at the moment. The features described here won't be in the Eclipse Feature until the Juno release, so look at the standalone as a preview of what's to come.
Automated version number management for About Dialog in Eclipse Products
06.03.2012 14:22 by Zeb Ford-Reitz
A while back, I was working on release engineering for GUIdancer, our Eclipse-based automated testing tool. As I was testing my changes, I noticed that the version number listed in the About Dialog was somewhat odd…
Note that the actual version number for GUIdancer is definitely not 0.4.0 (it's actually 5.2, going on 6.0)! And yet, the plugin.properties file wouldn’t lie:
aboutText=GUIdancernVersion: 0.4.0nn(c) Copyright Bredex GmbH 2004 - 2011
It turned out that I had inadvertently broken the script that automatically replaces the build number in all manifest files as well as the plugin.properties file based on a timestamp. Since a part of the release engineering changes separated the version numbers of GUIdancer’s bundles (such that they don’t have to all have the same version number), I had removed the reference to the script in the build process and neglected to replace it with some other form of automation. Our build tool (Tycho) takes care of updating the manifest files, replacing the ending “qualifier” string with an appropriate timestamp, but what about the as-yet-overlooked plugin.properties file? I was appalled at the idea of manually changing the version number in the plugin.properties file before every release. Above all, what if we forgot to perform the change before releasing?! We’d have multiple versions of GUIdancer out in the wild, all with the same version number displayed in their respective About Dialogs! The end result? Massive confusion for users and support teams:
Image ©caesararum,
http://www.flickr.com/photos/29707865@N05/2780508266/sizes/z/in/photostream/ licensed under Attribution 2.0 Generic (CC BY 2.0)
Not wanting to have that on my conscience, I started thinking about a way to automatically update the version number presented in the About Dialog. I settled on a solution combining plugin.properties, about.mappings, an Activator, and a Java Property. The relevant lines of the relevant files follow:
plugin.properties:
aboutText= My Foo Bar ApplicationnVersion: {0}
about.mappings:
0=$foo.bar.application.version$
activator:
public void start(BundleContext context) throws Exception {
super.start(context);
System.setProperty("foo.bar.application.version",
context.getBundle().getVersion().toString());
}
plugin.xml:
<extension id="product" point="org.eclipse.core.runtime.products"> <product application="foo.bar.application" name="My Foo Bar Application"> <property name="aboutText" value="%aboutText"> </property> </product> </extension>
All of these file belong to what I would call the “Product” bundle (the bundle that defines the org.eclipse.core.runtime.products extension point), which is then also the bundle that defines the version number displayed in the About Dialog. Using this tactic, I can once again believe what my Product says in its About Dialog.