Re: [TFUI] Is test driven UI development conceptually different?

I'm afraid the "UI Design" is an overloaded term, and that causes a lot
of confusion.  If you talk to someone like Larry Constantine, he'll say
it has to do with deciding what elements belong on the screen together
(gross oversimplification on my part).  He'll complain (rightfully so,
IMO) that TDD and refactoring will produce a crummy design.

But another meaning of "UI Design" is the design of the code that makes
the UI work.  As Ron Jeffries points out, this should be thin, but can
still harbor bugs.  This code *can* be developed with TDD.

A bit more than a year ago, Jeff Waltzer and I experimented with doing
so.  We were using java/swing.  We started with rolling our own
framework within jUnit, and found that we were basically re-implementing
jfcUnit, so we switched to that.

Our tests turned out to be not as fine-grained as we might for ordinary
java objects.  Whether that's the nature of GUI TDD or an artifact or
our inexperience is undetermined.  Our tests tended to be of the type,
"verify that a button markes 'GO' exists", "press the 'GO' button", and
"verify that the operation 'GO' was performed."  Since we were also
testing the functionality of our POJ objects separately, we did not mock
the underlying functionality, but presumed in our tests that it existed
and worked.  This led to our tests being a bit like acceptance tests.

Note that we did NOT verify that screen elements were in certain places
on the screen, or that the GUI was aesthetically pleasing (which it
wasn't).  We did visual verification visually, and casually.

This did give us functional GUI testing.  It ensured that the buttons
and widgets were hooked up correctly and functioning properly.  It was a
lot like plain old jUnit testing, though slower.  (Swing doesn't work
completely right unless you let it paint the screen.)

Is this the sort of thing you're seeking?

 - George

On Tue, Jul 27, 2004 at 03:22:10PM -0000, Jeff Patton wrote:
> After taking a quick scan of this list I'm seeing discussion on lots 
> of the plumbing around testing GUIs.  It was a quick scan, so there 
> might be more there, and this topic may have been discussed - so 
> forgive this post if it has - but here goes:
> 
> I develop in java and you couldn't pry jUnit out of my cold-dead-
> hands.  I use unit testing frameworks as a design tool in that I use 
> the testCase as a place to model the interactions one class has with 
> another.  I'm used to designing an object from the outside in.  I 
> see my test as the first client for the object(s).  I'd classify 
> myself as a state based tester: 
> http://www.martinfowler.com/articles/mocksArentStubs.html
> 
> So while I'm designing/testing, I'm imagining how best the classes 
> might collaborate, trying something out in a test, then making the 
> resulting object design support the test.  I'm confident my design 
> is good because I'm using it in the test code.
> 
> But, UI doesn't work that way.  If I'm designing UI test first I'm 
> addressign buttons programmatically, I'm filling in text fields 
> programmatically, I can't really "see" the list displayed on the 
> screen... I'm not really /using/ the UI in the same sense that other 
> test code uses the objects its testing.
> 
> I do design UI, and when I'm doing that I think about the users who 
> will be using it, their skills, education, domain knowledge and most 
> importantly their goals.  I arrange things in the UI visually to 
> support all those things - much like a carpenter might lay out tools 
> in a work-area so they efficiently support the work they're trying 
> to accomplish.  It's a visual task - and I'm acutely aware while I'm 
> doing it that I'm _not_ really the user who will be using this stuff 
> in the end.  It's sorta like method acting.  I have to imagine I'm 
> the person who will be using it.  I can iterate through and validate 
> lots of visual designs quickly using a whiteboard or pencil and 
> paper.  It's not at all the same as writing client code for objects -
>  because in that instance I really am the person who will be using 
> the objects.  And, I'll be using the obects in code - just like the 
> unit test code.
> 
> Where test-driven development for domain logic or other 
> architectural code seems like an act of design - I'm seeing test-
> driven UI as NOT an act of design, but an act of mechanically 
> building stuff that tests the already designed UI works as 
> expected.  This makes it feel tedious to me - especially considering 
> that it's so darn technically challenging.  And, after getting 
> challenging UI tests working, it makes me really not want to change 
> the UI - which feels exactly the opposite of other types of test-
> driven development where it empowers me to make more changes 
> safely.  
> 
> What's more, if I'm doing a good job keeping my UI thin - which I 
> think I do, I seldom have problems in the UI - and when I do, 
> they're do odd that can't imagine how I could have tested for them 
> programmatically. 
> 
> I do use Jemmy to programmatically test reusable components used for 
> form panels, tables, and trees.  I can test the heck out of those 
> abstrct components because their design is somewhat hardened... I 
> just need to make sure they work correctly so I can build apps out 
> of them dependably.  The way those components behave - the design of 
> their interactions - has been worked by building and manually 
> validating applications from a users _visual_ perspective.  They 
> weren't built test first. 
> 
> Summarizing: test driven UI development doesn't seem like the act of 
> design that other development seems like.  It seems tough to do.  
> The tests seem brittle.  The benefits don't seem to outweigh the 
> costs.
> 
> I'm fully aware that 4 or 5 years ago I said the same things about 
> test-driven development in general.  So, my opinions on the UI stuff 
> might very well be wrong.  But, I'd be curious to get feedback from 
> folks on this list - on anything or everything above.
> 
> Thanks,
> 
> -Jeff  


------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~-> 

To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org
 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/TestFirstUserInterfaces/

<*> To unsubscribe from this group, send an email to:
    TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/