Last October I blogged about GUI testing being hard and I meant that without the requirement of running as part of a Continuous Integration (CI)environment. Performing GUI automation within a CI environment imposes it's own unique challenges where tests have to be able to:

• Handle all cases where the GUI app fails to shutdown properly
• Handle unexpected UI from the GUI app (crash dialogs, Windows fatal error dialogs etc.)
• Terminate the application if it takes too long to respond
• Log output in the CI environments desired format (we had to add MSBuild output support to our test framework)

Additionally, the CI environment itself must allow GUI application execution. We're using the console version of CruiseControl.NET so we can monitor the status messages that appear. The console version presents a bit of a unique problem in that all output is captured so we're not able to see the test output during execution.

It's been 83 days since the aforementioned post and 790+ CruiseControl.NET builds (not all of which succeeded) and our GUI automation is humming along nicely. The test has caught numerous problems along the way and improved the overall quality of builds getting to QA. The QA smoke test, the first test QA runs on a build to determine if it's worth further inspection, has also been consistently passing at 100% for quite awhile now and it too is catching failures and saving valuable QA time and resources.

Of course there are many factors which have contributed to the overall success rate of our testing efforts for example:

• First and foremost we fixed 1,000's of bugs in BDS 2006 including the numerous patches we've released
• We committed R&D resources to improve and maintain our test framework
• The model generator I mentioned here which allows us to have up-to-date models with each build
• We've enabled R&D to develop their own GUI tests suites
• We're leveraging virtual PC's to quickly and consistently test a broad range of IDE/VCL features

One of the coolest Zombie tests I've ever seen is one written by Chris Hesik a few months ago. It tests both the managed and unmanaged debuggers by debugging the IDE in itself. The test:

1. Starts the BDS IDE
2. Loads a copy of it's own project group
3. Recompiles all of the packages from the entire IDE then the BDS.EXE
4. Sets breakpoints in the code
5. Launches BDS IDE under the debugger
6. Tests all sorts of debugger functionality

Now, that's a serious test! Above is just a brief summary of steps and hardly does justice to all of the work the test actually performs but if you've ever written GUI automation I'm sure you can appreciate what's involved in testing two copies of the same application where one instance is debugging the other not to mention running under CI. Chris and I spent quite a bit of time going over the finer details of how this was all going to work and I have to say he did a fabulous job of putting it all together. I'll ping him and see if perhaps he can write a blog post about it.

The IE blog has announced the availability of IE7 so be sure to install this reg file if you're running Borland's BDS 2005/2006 on the same system and you use the ASP.NET/HTML designer otherwise you're like to run into 'Access Denied' error messages.

Quoted:

...if you set a breakpoint and right click on it (in the editor gutter) to display the context menu you can select "Breakpoint properties..."

Have you ever tried debugging GUI code where focus changes cause code to execute that you didn't want executed? This is a fairly standard GUI debugging problem and one that Mark Edington (of Delphi R&D) recently discussed relating to debugging drag/drop code in the VCL. Having written a custom menuing system (in ActionBands) I've had my fair share of this type of debugging as well. I was helping Mark debug the above drag/drop problem and it occurred to me that it might be useful to mention a few breakpoint debugger features in our IDE that are likely overlooked by a lot of people.

For example, if you set a breakpoint and right click on it (in the editor gutter) to display the context menu you can select "Breakpoint properties..." (where you even aware of this menu item? :) ) that displays a dialog with various properties controlling how the breakpoint will function. There are many useful properties on this dialog which I'm not going to discuss here and you can read about them in the online help however, the ones that I'd like to point out I think are particularly useful for GUI debugging situations:

• The Pass count property allows you to set a value which represents the number of times execution passes this breakpoint before stopping.
• If you click the "Advanced" button you can see a "Break" checkbox that indicates whether or not the debugger will actually break at this breakpoint. Now, you might be asking what good is a breakpoint that does not break? Well, it can be good for lots of things and one of which is outputing useful debugging information. Just below the Break checkbox is a Log Message dropdown which causes whatever you've typed to be sent to the Event Log whenever the breakpoint is hit. One advantage of this is you don't have to litter your code with lots of OutputDebugString calls.
• Another option is Eval Expression dropdown which will cause whatever expression you've entered to be evaluated where the results can also be viewed via the Event Log.

I realize for some people this is probably old news but perhaps there are at least a few people who can benefit.

In C#Builder 1.0 and now Delphi 8.0 the IDE has a Welcome page which is little more than Microsoft's WebBrowser control hosted by the IDE pointing to a rather static HTML page.  In it's current incarnation the Welcome page is rather lacking but with a little creativity we can begin to unlock its potential.  Throughout the development of C#Builder and D8 for that matter, there were many discussions with some really good ideas (and a few bad ones too :) as to what should appear on the Welcome page but unfortunately by the time RTM rolled around hardly anything that was discussed had actually been implemented.  Since I work on the Internet features of the IDE and particularly the HTML/ASP.NET designers it was particularly frustrating to know the potential of the Welcome page and that we hadn't even scratched the surface.

Scratching the Surface

During the development of Delphi 2005 I decided that it was time to revamp the Welcome page.  Once again I heard similar mumblings about how to improve it and I finally decided it was time to act (I hadn't worked on the Welcome page in either D8 or C#B).  To that end I made a list (not necessarily in this order) of things I'd like to see on the Welcome page:

1. Have a familiar look-and-feel comparable to many modern websites
2. Provide dynamic content that's relevant to the developer audience
3. Provide extensibility allowing customers to tailor the Welcome page to fit their needs
4. Provide a good example of XHTML layed out using CSS

The first task was to review the current files that make up the existing Welcome page and see what I could use and what would need to be changed.  The layout that I had in mind was similar to many existing websites with a banner, a menu, the main content and a footer which the current design had two, the banner and the footer.  I shuffled the HTML around and built the structure of the page that I felt met these requirements.  Next, I started on the problem of dynamic content and how to keep the Welcome page fresh with new content but without requiring an entirely new infrastruture like Delphi Direct.

Enter RSS, XML and Javascript

Given the current popularity of RSS and the plentiful list of feeds provided by the BDN the decision of what content to include was pretty easy the hard part, or so I thought, would be getting the content onto the page without requiring that that IDE do all the work.  RSS is a defined XML format and the easiest way to programatically work with XML is via a DOM which is easily accessible from Javascript.  At first, I tried to create an implementation that wouldn't require too much of my time because I still had obligations for the HTML/ASP.NET designer.  What I came up with was a page listed the items from a single RSS feed (not to mention the recent projects table and a list of static links) but as it turns out this was just the beginning.

In the end, we created a Welcome page where the content is driven from XML files including the list of links and the available RSS feeds.  Out of the box you will be able to choose from a list of 45 different RSS feeds from a dropdown right on the page.

Leveraging the Welcome Page for Your Team

Internally, we've setup our own development blog server where anyone on the team can blog about internal issues,  announce new features as they show up in the product and notify the rest of the team about any potential problems.  Basically, the Welcome page has become a way for us to improve communication throughout our entire team.  You too can take advantage of this feature by setting up an RSS feed of your own and editing an entry in defaultProviders.xml located in .\welcomepage\xml under your Delphi 2005 directory.

I hope people find Welcome page 2.0 :) a lot better and I look forward to see where we can go from here!  Send me a comment and let me know how you like or dislike it.

Finally, I'd like to thank Daniel Wischnewski of the The German Delphi Community for all his help.  Thanks Daniel!

If you haven't already seen our DBWeb controls I highly recommend taking a look at them once Diamondback hits the streets. Our DBWeb controls are a set of data aware ASP.NET controls that allow you to not only manipulate data at runtime but also view the data on your WebForm at design time. If you haven't played much with ASP.NET you might ask "why is that a big deal?" since design-time data has long been available in the VCL form designer. Well, for starters when Microsoft shipped ASP.NET (1.0 and 1.1) their data aware controls required (and still do btw) data binding code before they will render any content which means they only render content at runtime.

For example, when you drop down an you see that it comes prepopulated with some fake data and that's all your ever going to see at design time. In a DBWeb control, once you connect it to an active data source you'll immediately see the data in the ASP.NET designer just like you see data in the VCL forms designer. Again, you might be saying to yourself "that's really no big deal I don't need to see the actual data". Well, picuture this you have a grid that once it's populated with data is going to run right off the righthand edge of the page you've spent so long making look really nice. Wouldn't you rather discover that as soon as you hook up the control rather than having to run the application for each and every control you add to the page to just to see how the control will morph when it contains data?

We first introduced our DBWeb controls in C#Builder and in Diamondback we've continued to improve them and add additional controls for things like sound and multimedia content. Additionally, you can feed the controls data from an XML file so it's easy to quickly prototype a data driven web site without even having to setup a database.

To start off I'd like to address the issue of why we need a formatter at all. Our ASP.NET/HTML designer leverages the MSHTML control as its design surface and as a result we have to deal with the fact that this control discards any/all formatting including whitespace preservation when working with HTML. If you'd actually like to see the effect of using MSHTML without a formatter (trust me you won't be happy) simply rename htmlfmt80.bpl in your Delphi 8 bin directory, start the IDE and answer Yes to the "continue to load this package" error and start editing an HTML file. This package contains our HTML formatter and without it you simply get back the raw HTML from the MSHTML control.

One decision we made in Delphi 8 was to format only the content of the file starting after the first tag. There were several reasons we did this but the main reason was that we wanted to format as little of the file as possible and since many pages have sections that contain stylesheet and scripting information we thought this would be a good idea. As it turns out this wasn't a very good idea and in some cases can result in HTML being either mangled or duplicated neither of which is good. It is possible in Delphi 8 to undo the changes made in the designer using Edit|Undo but that's not always acceptible either.

In Diamondback we've completely fixed this problem and not only improved our formatter but also have relaxed the rules for creating non-HTML documents using the ASP.NET designer. For example, if you want to create an ASPX page that returns only XML (like an RSS feed) simply start a new ASP.NET page and delete all of the contents except the @ page directive at the top of the file then start adding your markup and the designer won't mess it by trying to turn it into an HTML page. As a side note, we've continued to monitor the progress of the W3C's HTML Tidy open source project and have worked to keep our libtidy.dll up-to-date.

Diamondback, like Delphi 8, supports code completion on ASP.NET server controls from within the code editor as well as the tag editor.  This makes working with ASP.NET tags much easier and helps prevent mistyping tag and attibute names helping keep your development time productive.  In Diamondback we've changed the loading of schema files that describe ASP.NET server controls such that third party companies that produce ASP.NET controls and make their controls work like first class citizens in the Diamondback IDE with full support for code completion and HTML Error Insight (a topic for another day).

To take advantage of this feature all you have to do is create a .xsd file that looks like the ones provided with Diamondback and place it in the “..\schemas\asp schemas” under your Diamondback root directory.  When the IDE starts it loads all of the schemas from that directory for use with various IDE features like code completion.  If you are a vendor who already has a schema file for VS.NET then typically just dropping that file into the above directory will add first class support to the Diamondback IDE.