Ken Boucher wrote:
<and I bowdlerized>
> ...Joel on Software...
Dr. J ranges from illuminating to mostly harmless, but
he's very, very good at the verbiage conducting both.
(Can you detect a note of envy?;)
> ...The GUI is hard to Unit Test.
Why?
(I _know_ why, but I'm not being a Socratic Schmuck. I
need you to go first, so I can learn if I'm missing
anything.)
> It's hard to Acceptance Test.
Only if it's hard to Unit Test.
> We want it thin, so thin as to not matter.
We want _everything_ thin. Don't make something fat
just because it's easy to test!
> ...HTML, CSS,
> and Javascript, and you still need the really bright
> UI guys.
Right. But you don't need cowboys. That's on you, not
those bright skript kiddies.
("That's on you" is street argot for "that's your
responsibility".)
> Now I firmly believe that agile is the right way to
> do GUIs. But I
> also belive one thing: It's A Different Kind Of
> Agile*
You bring up these issues...
- the TFUI mailing list
- the agile-usability mailing list
- high-content programming, such as Web sites or
games
Normal programs work with small, non-colorful
variables, containing numbers and text. When you work
with a lot of big flashy content, testing it is hard
and impractical.
> ...looks more like
> Geocities than it
> does Microsoft excel...
Content directly influences usability, in ways tests
shouldn't try to constrain. Our GUI Toolkits exist to
permit dynamic content changes.
And however, users are hard to refactor. So our
project must define a good GUI before the first
delivery, and must preserve its usability after
delivery.
> ...And that makes me think that someone else
> should be definately
> be doing the GUI...
GUI work has customer-team aspects.
> ...And I think they would be testing
> different.
No. When you hit The Test Button, all your tests run.
Even ones doing disturbing things to GUIs.
What's different is how we get what we want from
testing. We want automated review, and immediate
feedback. If we automate the review on other channels,
then we don't need to test every pixel.
> Wouldn't it be interesting if they mocked up the
> entire model and
> built some form of test suite that really beat
> against all the things
> we forget GUIs do?
Don't mock a GUI Toolkit. There's always another way.
Tests should run quickly and quietly. There are some
few systems that absolutely require a noisy test. Move
these to your integration tests.
> Different people with a different problem and
> different practices
> focused on the reality of their situation. What
> would it look like?
It would look like this page, which I added 2 days
ago:
http://www.c2.com/cgi/wiki?BroadbandFeedback
Quick! Read it before some a5e spams it!!!
=====
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
