Home > GUI, software development, test-driven, testing > Did I say don’t unit-test GUIs?

Did I say don’t unit-test GUIs?

Isn’t life funny? Two weeks ago I stated my opinion that unit-testing graphical user interfaces isn’t worth the trouble. Now I find myself doing it, writing unit-tests for GUI components.

What happened, did I come to my senses or go crazy (pick the expression that fits your point of view) during Christmas holidays? No, I still think that unit-testing user interfaces is most likely a waste of time, but for some special occasions, like this one, they will pay off.

My task is to make changes to a tool box control in a legacy application. The control is full of application logic and it has a strong and complicated relationship to an edit area control. There are two things I need to do:
First I have to pull out the application logic of the tool box and break the tight relationship to the edit area. Then I need to push that application logic deeper into the application core, so that the tool box could be used via the plug-in framework.

I figured I had two options. I could either refactor the tool box and make the changes in small steps, or I could rebuild the complete tool box logic and then change the controls to use the new programming interface.
I found the rebuild alternative too risky. The code base is full of booby traps and I have to be very careful not to introduce bugs. Therefore I decided to go with refactoring.

But refactoring requires a unit-testing harness, which of course this application doesn’t have. Trust me; you don’t want to refactor without extensive unit-testing, so here I am setting up the tests around the involved GUI controls. It’s a lot of work, especially since I don’t have a decent framework for creating mock objects, but it’ll be worth the effort once I start messing around with the code.

As a conclusion I’d like to refine the “Don’t unit-test GUI” statement to read “Don’t unit-test GUI unless you’re refactoring it, and there’s no easier way to make sure your changes doesn’t break anything.”


  1. yperi
    December 26th, 2008 at 20:36 | #1

    I read with interest the previous thread, and now this follow-up.
    I work in GUI many years, and gained some experience.
    It was nice to see you bending towards I guess the next one will be: “… Oh yeah, and unless you are using a complex data-cache logic. But thats it! Other than that, do not waste your time on GUI testing.”
    And 3 weeks later, you might add: “Well, hmmm, there is a tiny chance that you will need to develop a real complex component like a visual schematic editor. But this is really the only case you need to test the GUI…”

    So, you already see my point: GUIs can get very complex.
    Look at Visio, look at Photo Shop, even at iTunes.
    More over, even GUIs that looks simple might implement complex mechanisms to optimize performance, to support selection dependencies, implement lazy-fetch mechanism etc.

    I suspect that you, as well as most of the other people that responded to the previous thread had only experience with a basic GUI components and logic. This also explains the link to the Humble Dialog Box paper.

    If your GUI world narrows down to designing a Dialog Boxes, than, then your arguments are valid.

    But in the last 10 years when I was planning, architecturing, designing, implementing and automatically-testing GUIs, I must say that the least challenge was designing of dialog boxes.

    So, I would rephrase your say with: “Always unit-test GUI unless your GUI is (or can be be) really really simple.”

    Saying that I must admit that unit-testing of GUI is not trivial. Especially if you want to use the same automation solution that runs your regression testing.

    I am exploring that area now, and probably soon will start draw some directions for how to do it…



  1. No trackbacks yet.