By bloid
via regdeveloper.co.uk
Published: Oct 24 2007 / 03:35
It can be dangerous to make sweeping "Don't" statements. In Patterns of Enterprise Application Architecture, agile guru Martin Fowler coined his now-infamous first law of distributed object design: Don't distribute your objects. This is good advice to an extent but is also an overly simplistic viewpoint. The reader is left to track down the exceptions to the rule.
With that in mind, I'm going to propose (and then shoot down) an overly simplistic law of unit testing GUIs: Don't unit-test GUIs. It's more trouble than it's worth, and you end up grappling with object lifecycle issues, heavyweight/time-consuming unit tests that create GUI components or stop and wait for user input in a "headless" build environment, and so on. Whole open-source projects have sprung up to try and solve these difficulties: and this in itself is an indictment of the futility of automated GUI testing.
Comments
larsgregersen replied ago:
Unit testing of GUIs is absolutely necessary. How are you else going to find out that you have a control that sends its data to the wrong place? or tries to read invalid or nonexisting data from an object in your applicaiton. Or that you have forgot a control? Or you have code that places a control on a tab that doesn't exist anymore...etc.
Surely, static testing can do a lot for you, but some things you can only test for at run-time.
Manual testing of applications with hundreds of dialogs is necessary because you still need someone to see if the layout is OK and the application is usable and user-friendly, but for the day to day testing of GUIs you still need automatic testing.
Ryan Ginstrom replied ago:
I also believe that GUIs should be unit tested, as well as function tested. I wrote a little blog article on unit testing wxpython GUI code -- it's actually quite easy. (http://ginstrom.com/scribbles/2007/09/18/mocking-wxpython-for-unit-testing/)
On Windows, pywinauto and AutoIt make it very easy to function test GUIs as well.
Just about the only times you should be poking around clicking buttons manually (IMHO) are (1) dog fooding, (2) useability testing, and (3) prototyping/designing.
Voters For This Link (12)
Voters Against This Link (5)