Comments on: Did I say don’t unit-test GUIs? http://www.hans-eric.com/2008/01/03/did-i-say-dont-unit-test-guis/ Hans-Eric Grönlund on software development Thu, 29 Jul 2010 15:10:19 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: yperi http://www.hans-eric.com/2008/01/03/did-i-say-dont-unit-test-guis/comment-page-1/#comment-23638 yperi Fri, 26 Dec 2008 20:36:36 +0000 http://www.hans-eric.com/2008/01/03/did-i-say-dont-unit-test-guis/#comment-23638 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... Thanks, Yaron. 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…

Thanks,

Yaron.

]]>