Usability and CDT 4.0

When we first began developing our C++ tools we wanted to see what usability issues developers would face so we ran a series of testing sessions with people new to Eclipse, people who had used Eclipse for Java development, and people developing with Visual Studio.

The bug 154280 has more details but my story here is that the issues on the front line have been addressed in Europa.

When we asked people to build a newly created project they looked for a build button in the toolbar. (The platform has a Build All button but it's not easily identifiable and it builds all).

Now CDT 4.0 includes a Build Project button that builds the active configuration of the selected project and has a menu that lets you build any of the other ones.


When we asked people to debug their project they naturally hit the Debug button and ended up getting confused by the Launch Configuration dialog.

Now CDT 4.0 takes advantage of the new debug platform support for contextual launching: Hitting the debug button now does what people expect, launching a debug session for the selected project and using the launch shortcut to ask for any settings it needs along the way.

We're tracking lots of other usability issues from C/C++ developers but I'm pleased these two big out of the box problems are fixed in Europa.

Would you like JDT with that?

In a recent conversation in bugzilla someone asked if it was common for people using CDT to also have the JDT installed. The short answer is "yes" but that's not always because they are developing in Java as well as C++.

When people start with our Carbide.c++ they run a branded installer like you get with most Windows apps and you get an entry in the Start menu etc. We install a JRE and a bunch of Eclipse features but not the JDT. People focused on C++ development didn't want to see "all the Java stuff" so we left it out.

But people who are also doing Java development (sometimes developing plug-ins for Carbide) or who already have Eclipse configured with their favorite plug-ins can just take our Carbide features and merge them in. Corporate IT people often like to have a standard version of Eclipse that usually includes the JDT since it is seen as part of the base platform. Also some plug-ins out there assume the JDT is present and will not work correctly if it isn't. So we've got to assume there is a good chance the JDT will show up at some point.

I recall one of the sessions at EclipseCon this year where the presenter was showing Eclipse with all of the Europa plug-ins (and maybe some others) installed. The UI was an impressive jumble of widgets and completely confusing. Someone said something about capabilities being useful but added that "no one uses them."

I was surprised as we use capabilities extensively to keep the user experience focused on C++ development when people are using Carbide, mostly by hiding CDT UI that isn't used when developing apps for Symbian OS. At some point I'll have to see if we could start including the JDT but keep the UI subdued unless you start working with Java projects.

Structuring C++ Projects in Eclipse

We’ve been struggling with how to represent C++ projects in Eclipse so I thought I would share our story in case anyone can offer any better suggestions:

It’s common for developers to already have their code organized something like this:

/Source/Projects/CPPProjectOne/src – project one specific code
/Source/Projects/CPPProjectTwo/src – project two specific code
/Source/Projects/CPPProjectThree/src – project three specific code
/Source/Projects/Common/src – source common to all CPP projects

We can not copy the source files to another location or move anything around, we have to work with them exactly where they are in the file system. Since for each project we call a custom make builder that doesn’t depend on anything in Eclipse the main thing we want our Eclipse projects to do is contain as much of the code as possible so that all of the splendid IDE features work correctly.

Our first thought was to put the Eclipse projects in the workspace and then stuff them with linked resources to the actual source files and folders. That seemed like a great fit for linked resources and would be fairly straightforward to do. However we discovered that linked resources are not really first class citizens in the workspace: to begin with they don’t work with version control (41929) so we had to abandon that idea.

Our next try was to just locate the Eclipse project and it’s source root where the cpp project’s code actually lives. When we import a cpp project’s make file we can look at the included sources and determine a root location that covers all the files. So using the above example CPPProjectOne’s source root would be /Source/Projects. This works OK, we end up with an Eclipse project that lives at /Source/Projects/.project and includes resources for all of the desired files (plus lots of other stuff too).

The trouble begins when I want to work with CPPProjectTwo at the same time. I find that it has the same common source root location as CPPProjectOne, but I can’t put a second Eclipse project there as a .project file already exists in that location.

The best work around we have been able to think of for now is to have the second project use a more narrowly scoped source root, in this case it could use /Source/Projects/CPPProjectTwo. But that will leave other files it uses, like those from /Source/Projects/Common/src, out of the project.

If we could either put more than one Eclipse project in the same location or tell a project to use something other than its location as a source root (78438) then we could accommodate any number of projects. Or if linked resources worked better we could use those. Just now we’re stuck telling people to try the work around but we need to determine what direction to pursue longer term so we can make this work the way people expect.

Carbide 1.2 is Out the Door

We've completed the final build for Carbide 1.2 so I can come up for air now. Carbide 1.2 is using Eclipse 3.2.1 and a modified version of CDT 4.0M5. Taking the risk on a pre-release version of CDT has worked out well: the code navigation features bring us much closer to what people expect and we've seen few problems. Over the last couple months our team has been helped by a great beta group of several hundred people testing Carbide in a production environment with lots of sizable real world projects. This has been illuminating and occasionally humbling as people told us what we had to deliver to pull them away from their current C++ development environment. We couldn't get all of it into this release and so we're left with a lot of raw feedback to distill into specific fixes and enhancements for next time.

Now I need to move ahead with work on my CDT bug list and planning for the next Carbide release which will use Eclipse 3.3 and the final version of CDT 4.0. How did it get to be mid April already?

Jolting News

Since returning from EclipseCon I'm mostly had my head down focused on fixing bugs in the final few weeks before we ship Carbide.c++ 1.2. Then came the announcement last week that Carbide 1.1 had won the Jolt award for best mobile development tool! We had been runner up the year before but this time we beat out NetBeans and few others to capture the Jolt. Since we're all focused on the next release it's nice to get some recognition for the last one.

CDT 4.0 Demo at EclipseCon

Doug Schaefer and Markus Schorn just finished a great demo of the new features in CDT 4.0 to a packed room. We're shipping our next version of Carbide with a customized version of CDT 4.0M5 and after a couple weeks of internal testing and a week in front of our beta testers things are looking very good. The improvements in code editing and navigation are really a big leap forward for CDT.

Automated UI Testing

Our team has been adding automated UI testing to our JUnit tests over the past year. Since there seems to be growing interest in doing this I thought I would tell our story.

To begin with our developers wanted to run JUnit tests and our test team wanted to automate much of the testing they were doing by hand. It made sense to combine those efforts and have one set of tests everyone could run and contribute to. But we couldn't test everything we needed from JUnit without the ability to occasionally punch a button, enter text into a wizard, or choose a menu item.

We looked at tools that let you record user actions and then play them back. This makes a great demo and has immediate appeal to what many people initially think they want from automated UI testing. If you are a test team that is given a product and you just want to automate what would otherwise be a laborious manual test effort this is probably the best you can do. But tests constructed this way are often fragile and superficial: minor UI changes can break them and they don't really know what's going on underneath. We wanted our development and test efforts to be better integrated so we looked for a way to drive the UI from our JUnit tests.

We ended up using Abbot to do this with pretty good results. Abbot also has a script editor/recorder called Costello that doesn't work with SWT yet. I think this has led some people to think Abbot doesn't work with SWT at all, but we were interested in the stuff that we could call directly from our JUnit code and got that working right away.

Much of Abbot is pretty low-level and we ended up building a utility layer on top of it to handle common tasks and boilerplate code. This was easy to do and makes the code that uses it a lot cleaner.

A problem all UI testing tools have is identifying the exact widget to act on. If it doesn't have a unique name you have to do something fragile like reference it by relative position to known widgets. Even if it is something like a button that has a name like "Cancel" the test will break as soon as 'Cancel" is translated to another language so you'll need to translate that portion of the tests as well. The solution is to give significant SWT widgets unique IDs when you create them. This is easy to do so we started adding the ID to any UI that we create for Carbide. Of course that leaves the UI from the platform and CDT so there are still plenty of cases where we have to hunt around for the correct widget.

Our tests can drive the UI faster than any human could. This can lead to false problems with the test: it may click on a button in one view and then want to look at an expanded tree item in another view but the tree doesn't expand instantly. Events often have to ripple through the platform before the UI settles down. There are places where you may need to insert a pause to make the test work reliably. This has to be done judiciously because there may be someone out there who downs enough coffee to turn what seems like unlikely behavior into a real bug.

With the addition of Abbot we've been able to write tests that automate much of the debugger in CDT. While some of the tests in CDT are updated and run with every build the debugger tests are out of date and wouldn't provide the same level of coverage. I'd like to get our general debugger tests into CDT as most things can be tested the same way regardless of the debugger engine on the back-end.

I've glossed over a lot of detail but I think that when looking at automated UI testing tools it's best to begin by deciding if you want to integrate them into a test driven development cycle. In many organizations testing is a completely segregated function done by people who aren't in a position to collaborate with developers on JUnit tests and so one of the record/playback/scripting tools is probably the best option. But for Carbide.c++ we've been able to use Abbot to extend the reach of our JUnit tests for a more integrated and comprehensive approach to testing and development. Now we just need to build more tests...