Test First User Interfaces (Last Edit: Mar 17 2005 09:46:44)
RecentChanges Edit Search GoodStyle
Referenced By: ExtremeProgramming, XPSDMeetingMinutesSep4

The temple is Ankor Wat. I chose it because it's so damned groovy, and kind'a fractal.

The mailing list:

Wiki:TestDrivenDevelopment has a steep learning curve, but phenomenal rewards await on the other side.

The TDD literature focuses on fresh new logic, written from scratch, using languages and generic libraries that assist testing.

But some legacy code resists test fiercely. Wiki:GuiToolkits damage the TDD learning process by resisting queries on visual states, by neglecting internal test problems in their documentation, and by coupling to false conveniences, such as scripting languages, wizards, form painters, and integrated debuggers.

The current crop of GUI toolkits either raise a window or die trying. This interrupts flow, and interferes with unattended tests. We must research each toolkit, individually, to learn how to make it "just another library", completely obedient to our code, with little or no side-effects on the screen.

The solution is to re-express the emergent rules of TDD into GUI terms, so we devote the correct amount of energy to overcoming GUI code's specific problems. There is a role for everything - even wizards - but we will unfortunately find ourselves re-inventing many Wiki:TestFixtures as we go. Our industry will eventually share these, and the GUI tool vendors will eventually incorporate the fixtures into their offerings.

Most GUI libraries support the ability to define a high-level window operation without displaying it. This supports slow environments that must fully populate a window before committing it to hardware, as an optimization. Test code can then query the invisible window's state back, and throw it away without displaying it.

When you test-first, after making a few edits, hit one button in your editor, and put every test under that button, unattended.

If a test must raise a GUI, it must create its widget objects, drive them, and croak them, all without manual interaction, and hopefully without even displaying.

While the GUI secretly displays, the keyboard should retain the focus and be unblocked. You could start your next edit while the tests run. Your system (or at least your muscle memory) must retain a checkpoint that you can roll back to, before the current test's state, if it fails.

For each test, you should have the ability to optionally display that window, in an intermedate or fully tested state. This is so you can examine and click on the window in the same state as a user would have driven it to, but without driving it every stinking time you test.

Further, because you must be able to integrate freely, this system that optionally displays must key to your computer's USER name. So if you integrate and others outegrate, they don't get windows popping up while they test.

A lite sample of TDD in action for GUI: http://www.rubygarden.org/ruby?SvgCanvas

[Question for Carlton or John - how to add a Remote Link? Such as RubyGarden?:SvgCanvas? (I remind you MiniRubyWiki? can do that very easily.)]

Contrarily, many systems intermediate between the graphical operations and their eventual display. To test HTML, only write pure XHTML, and use XPath? to query that it contains what it should.

The best full-featured example so far is Wiki:RemoteUserInterface

Finally, much testing must exploit automation hooks in the rendering environment. The latest tests for this project...


...drive Internet Explorer to simulate users clicking on advanced HTML forms:


Get the source here: http://rubyforge.org/cgi-bin/viewcvs/cgi/viewcvs.cgi/cvs_root.tar.gz?tarball=1&cvsroot=minirubywiki

TODO - upgrade the MRW site on that server TODO - wale on Peet to send the old MRW pages

See http://gnomesupport.org/wiki/index.php/TestDrivenDevelopment , TfuiForMfc