Test Automation For .NET Winforms Applications

I had been searching for a decent test automation tool for one of our .NET client/server applications for quite a while now.

Of course there is NUnit for unit testing, but our application is very userinterface-heavy, and while we will continue to provide NUnit test cases, they only cover one part.

Then there are the big players in user interface test automation like Rational Robot or Mercury QuickTest. But the licensing costs seemed disproportional here.

We actually have applied some of those tools on other, larger projects, e.g. I used to work on an Enterprise Java solution where one of my colleagues was solely responsible for maintaining and running a suite of test cases (Rational Robot mainly). For Java web as well as Swing rich client applications there is Apache JMeter, but I don't know of any .NET port. HttpUnit allows for testing at HTTP level by emulating browser behaviour. In .NET land we now have Microsoft Software Tester Team Center for Visual Studio 2005 / .NET 2.0. I am very impressed with what I have seen about Team System in general, but in this project we are stuck with .NET 1.1 at the moment.

One product I was particularly interested in just was a real pain in getting it up and running - downloading and registering additional plugins, just do find out it wouldn't work, that kind of stuff. So I gave up on that one. Of course, this vendor will have a sales representative call in some days after you filled in the download form. All I wanted was to download the trial version (if they ask for my email that's OK, but having to enter my phone number usually is a warning sight), and have it up and running within five minutes so I can start playing around. If that's not possible, it's a no-go.

Besides I only digged out some half-baked freeware solutions for .NET. Of course, as .NET WinForms are based on native window handles, any Win32 user interface test tool might have been fine as well. User-drawn controls are a little problem, as the test tools cannot attach to any handles of child controls, so they will only record screen coordinates on mouse-events. E.g. if your pulldown menu is user-drawn (the whole menu is represented by one single Window handle, but there isn't a Window handle for each menu item), and you add another menu item on top of others, your mouse-click coordinates won't fit any more.

Anyway, one of my colleagues finally stumbled upon AutomatedQA TestComplete. It was easy to use from the first moment on, came with all the features we need, had strong scripting capabilities, and was labeled at a fair price (USD 499 for the standard edition). Right now we are in the process of assembling a little test script library, and we are recording our first test cases. After a test case has been run, the script continues to check the database for valid processing. We are planing to run those scripts automatically each night on the latest source version.


I will continue to report about our experiences with TestComplete.

The Upside-Down-Ternet

So if your wannabe-hacker neighbour intents to steal bandwitdh from your WLAN, instead of using WPA you could rather turn the (ip)tables and set up his own Upside-Down-Ternet.

Gates, Jobs, And The Zen Aesthetic

Garry Reynolds compares Bill Gates' and Steve Jobs' presentation styles:

• Bill Gates and visual complexity


• Gates, Jobs, and the Zen aesthetic

Software Engineering Radio On Model Driven Software Development

Great series of podcasts on model driven software development by the folks from Software Engineering Radio. I spend some time last weekend listening to...

• Episode 5: Model-Driven Software Development (Part 1)


• Episode 6: Model-Driven Software Development (Part 2)


• Episode 16: Model-Driven Software Development (Part 3 / Hands-On)

... and also pointed my coworkers to those episodes in order go get all of us jump-started on MDSD, a topic which will be becoming of major importance in one of our upcoming projects.

Ruby On Rails

If you are developing web applications under J2EE just like me, and also grew increasingly curious about all that hype around Ruby on Rails lately, you might want to have a look at the screencasts available at rubyonrails.org. Having watched some of the presentations, it's certainly too early to draw any conclusions yet. All I can say is that Ruby on Rails looks like an extremely productive environment. Hacking prototypes that way seems like a very natural thing to do. On the other hand, there is a lot of magic going on. And I don't like magic, at least not too much of it. I am also one of those old-fashioned developers who prefer to pass their code through a compiler before running it. Still, I will definitely take a closer look on Ruby on Rails as soon as my schedule allows me to.

Gates To Leave Day-To-Day Role At Microsoft

News of the day: Microsoft announced Thursday that chairman and co-founder Bill Gates will transition out of a day-to-day role at the company, effective July 2008, to spend more time working on his charitable foundation.

Having read a lot on Bill Gates' biography over the years, I am a little bit surprised by this step. He had been showing such a lot of drive and dedication for the software business for more than thirty years. The people who challenged him, Gary Kildall (DR), Mitch Kapor (Lotus), Ray Noorda (Novell), Jim Cannavino (IBM), Philippe Kahn (Borland), all of them kissed the dust sooner or later. I am not sure about Eric Schmidt and Google yet ;-) Anyway, and whether people like it or not, Gates is leaving the ring as undisputed champion.

Dolphin Filemanager For KDE

My friend Peter has now published a first alpha version of his Linux filemanager codenamed "Dolphin". It is being implemented in C++, based on Qt. I know Peter's works from several years of joined efforts on a C++ framework, so I can really recommend Dolphin to Linux desktop users in KDE camp. Unlike Konqueror, Dolphin supports file operations exclusively and emphasizes on usability and performance.

Please give it a try, and tell Peter what you think about it.

Totally GridBag

Ironically I found this video scoffing at the infamous Java GridBagLayout the very same day I helped a friend on some GridBagLayout code. I thought I had finally achieved GridBagLayout mastery after years of practicing ;-). One of the first things in any AWT or Swing project used to be a subclass of GridBagConstraints with some convenience constructors for setting the property values all at once. But in the days of UI designers like Matisse I seem to have forgotten again some GridBagLayout specialities. Well, maybe that's not even a bad thing.

Marc Andreessen Speaks At Berkeley

Sorry for not posting in a while, I am once again in release crunch mode.

I listened to Marc Andreessen speaking at the UC Berkeley Distinguished Innovator Lecture series the other day (webcast link, podcast feed), talking about career decision making, the fallacy of working in large corporations and how tech startup venture capital funding changed within the last ten years. He also mentions that after graduating - while expecting to be a programmer for the rest of his life - he only worked as a software engineer for about three months (supposedly referring to his short interlude at Enterprise Integration Technologies before founding Netscape together with Jim Clark). Supports my impression that he didn't really do any coding on Netscape Navigator.

Jeff Atwood On Egoless Programming

Jeff Atwood quotes Gerald Weinberg's Ten Commandments of Egoless Programming (from his 1971 book "The Psychology of Computer Programming"):

1. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
2. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don't take it personally when one is uncovered.
3. No matter how much "karate" you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it's not needed.
4. Don't rewrite code without consultation. There's a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
5. Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience.
6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
7. The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect—so if you want respect in an egoless environment, cultivate knowledge.
8. Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don't take revenge or say, "I told you so" more than a few times at most, and don't make your dearly departed idea a martyr or rallying cry.
9. Don't be "the guy in the room." Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
10. Critique code instead of people—be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

Those statements are of timeless truth. Hey, and I got a copy of "The Psychology of Computer Programming" on my bookshelf, but it has been quite a while since I read it.

The Pragmatic Programmer / Tip 11

Use the Power of Command Shells
Use the shell when graphical user interfaces don't cut it.

More at the pragmatic programmer list of tips.

Performance Tuning

I recently spent something like two days performance-tuning someone else's code. This included a handful of SQL statements and visualization stuff in C#. Several things had gone wrong, some missing database indices here, suboptimal SQL queries there, and a lack of understanding for what happens on under the hood of certain .NET framework methods. Performance penalties which might not hurt on a resultset of some hundred rows (or even occur unnoticed when no one pay attention), will cause disaster once database tables grow to some hundreds of thousands or millions of rows. And you don't want your customer to find that out in a year or two. Your goal is to avoid things like that from happening from the very beginning on.

In larger projects there should be at least one person solely responsible for testing and improving performance. Those are the guys who will rap the developers' knuckles when they chose wrong approaches. They normally have their test automation tools along with a set of load and stress cases at their disposal. And they know how to tune performance.

Small to medium size projects often don't carry that kind of luxury. Anyway, raising the developers' grasp for runtime issues is important in either case.

The Pragmatic Programmer / Tip 10

Iterate the Schedule with the Code
Use experience you gain as you implement to refine the project time scales.

More at the pragmatic programmer list of tips.

The Pragmatic Programmer / Tip 9

Program Close to the Problem Domain
Design and code in your user's language.

More at the pragmatic programmer list of tips.

The Pragmatic Programmer / Tip 8

Use Tracer Bullets to Find the Target
Tracer bullets let you home in on your target by trying things and seeing how close they land.

More at the pragmatic programmer list of tips.