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

Jeff, thanks for your thoughts - very interesting. I don't seem to have the
problems you do with TDD of UI. Firstly, the screen design itself will be
done as a separate exercise with someone who cares very much about the
ergonomics. This is never boring rather it is fascinating and rewarding
trying to get a fast efficient pragmatic UI.

Secondly, if there are any complicated tests it indicates to me that I am
probably doing something in the UI that I shouldn't be. So it is part of the
design exercise to me.

Thirdly, I try to treat my UI objects as I would any other. I send messages
and expect responses.

Finally (for now), I am conscious that the tests are partly there to make it
easier to make changes in the future. I have a library of simple assertions,
e.g. AssertTabOrder, and functions (e.g. ClickButton) to simplify the
process.

In summary, there are parts that make it different, as you say, it can be
tedious, but it is worth it.

Phran Ryder

Manchester_sdc (Service Development)
Network Phone: 617 5651
External Phone: 0161 932 5651
Email: [email protected]

Address:
Centron House
Rowlandsway
Wythenshawe
Manchester
M22 5SQ


-----Original Message-----
From: [email protected]
[mailto:[email protected]] 
Sent: 27 July 2004 17:24
To: [email protected]
Subject: [TFUI] Digest Number 172


There is 1 message in this issue.

Topics in this digest:

      1. Is test driven UI development conceptually different?
           From: "Jeff Patton" <[email protected]>


________________________________________________________________________
________________________________________________________________________

Message: 1         
   Date: Tue, 27 Jul 2004 15:22:10 -0000
   From: "Jeff Patton" <[email protected]>
Subject: Is test driven UI development conceptually different?

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  





________________________________________________________________________
________________________________________________________________________


To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

------------------------------------------------------------------------
Yahoo! Groups Links



 
------------------------------------------------------------------------



---------------------------------------------------------------------------------------------------------------
This e-mail is intended only for the above addressee.  It may contain
privileged information. If you are not the addressee you must not copy,
distribute, disclose or use any of the information in it.  If you have
received it in error please delete it and immediately notify the sender.

evolvebank.com is a division of Lloyds TSB Bank plc.
Lloyds TSB Bank plc, 25 Gresham Street, London, EC2V 7HN.  Registered in
England, number 2065.  Telephone No: 020 7626 1500
Lloyds TSB Scotland plc, Henry Duncan House, 120 George Street,
Edinburgh EH2 4LH.  Registered in Scotland, number 95237.  Telephone
No: 0131 225 4555

Lloyds TSB Bank plc and Lloyds TSB Scotland plc are authorised and
regulated by the Financial Services Authority and represent only the
Scottish Widows and Lloyds TSB Marketing Group for life assurance, 
pensions and investment business.

Signatories to the Banking Codes.
---------------------------------------------------------------------------------------------------------------



[Non-text portions of this message have been removed]



------------------------ 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/