Colleague sent me this commercial about the Citröen that lampoons the Transformers… and, unless it’s a joke, here’s reality getting back at parody again: leaked ILM footage of a live action Transformer. Which be totally sweet. Please make that movie.
I’ve been thinking a lot about how to [tag]unit test[/tag] [tag]UI[/tag]s in [tag]C#[/tag]. There’s this trope that I hear again and again from developers: “Unit testing a user interface is nigh impossible.” I think anyone who has worked with thick client UIs(user interfaces) should go and have a looksee at the programs available for testing the user interaction with those UIs. Most of them rely on pixel-interaction and, on Windows, sending fake Windows messages directly to the message pump of the application being tested. Both of these methods seem error prone and like deadweights around the neck of an [tag]agile[/tag] process. In a sense, these kinds of heavy user interface tests are a rigid kind of documentation of a UI and not a very expressive one at that.
One of the things I like best about NUnit is that the unit tests become declarative statements about the units being tested and, by extension, the program itself. The unit tests become a sort of negative space around the map of the correct functionality of the units and serve to document those units in a very expressive way. Each small test not only gives the assurance of correct functionality but serves to define what that functionality is and explain it to the reader. The tests play multiple roles: as guarantees and as documentation. That is fantastic.
I think a tool that could help test UIs would also serve multiple purposes. I think that it would not only help define proper interaction and proper states but also help keep UIs standard across far-flung organizations.
So why isn’t there a tool like that for testing UIs? I think, in part, because people become wrapped up in the presentation of a user interface and forget that there’s a logical structure underneath it all, waiting to be exposed. I’ve heard many times that, “If only the UI was built more as an MVC then we wouldn’t have this problem.” Wrong. An MVC exposes a model in a view whose interactions are externally controlled, sure… but I don’t think this particular design pattern is flexible enough to simultaneously maintain proper UI state, make a programmer’s job easier, and enforce UI standards across an organization. We need something that will address all those at once.
Maybe a correct approach is to think of most UIs as a kind of state machine (or maybe several interlocking ones if that is simpler). Each piece of the UI mosaic contains state (enabled/disabled, checked/unchecked, valid/not valid) that relates back to the whole and can be used to draw conclusions about that whole (user can enter text here but not here, user can click there but not there, etc.). I think this state machine is separate from the model and the view and shouldn’t be in the controller at all. It should express concepts about the UI, and contexts about the UI, without specifying “button this” or “menu that”.
To segue a bit… I’ve also been using Spring, a very cool IOC/DI(dependency injection) tool, which has taught me that a simple shift in paradigm can reap enormous benefits. Utilizing Spring has made my development life much more pleasant: my objects are more testable, my interfaces more meaningful… in general, the app is much more flexible. By using Spring and adapting the code just a little bit I feel like the codebase has greatly improved.
In that way it is similar to Rails. All that Rails asks is that you, the developer, shift your focus a bit and follow some conventions. The leverage that it provides as a framework creates enormous productivity gains while the models it provides engender a paradigm shift in what I think is the right direction: less grunt work, more concept work.
Which all brings me back to my pie-in-the-sky UI testing guy (Rhyming is Good): Who wants to hand check every UI that the team produces to make sure that it is pixel perfect in order to match UI standards for a company? Who wants to spend time adapting UI tests because usability tests indicated that the buttons should be a bit narrower and shifted down a few pixels thus throwing off the auto-clicker UI tester? Who wants to spend concept time doing the grunt work of tracking down why the damn “Save” menu item is enabled when the user hasn’t dirtied the editing window yet? Man, not me.
So here we are. I think good UI unit testing has to follow these rules:
Parking#, restoring parks to our city’s inner space one vehicular rental space at a time.
Dive into Accesibility is one of the coolest web usability sites I’ve seen in a long time. It has great little gems like the Lynx viewer (what does your site look like using Lynx to give you an idea of what people with visual disabilities hear first?) and Vischeck, a neato interface for seeing what your site looks like for people with varying forms of colorblindedness.
Frickin’ sweet. So that’s what this guy did after writing “Dive into Python”. Heh.
How many flies does it take to screw in a light bulb?
Two, but no one can figure out how they get in there.
Magic is real unless declared integer.
And Sean can tell this blonde joke with better nuance than I ever could.
This guy is amazing. He has a neato maze classification rundown on his site as well.
And sometimes I’m so funny I—well, you know.
Martin Fowler has some neat things to say about humane interfaces... the basic idea being that you want interfaces that work the way you do instead of being minimal and complete. Fowler talks a bit about duck typing in Ruby as a sort of continuation of the earlier article.
Interesting. This banged around in my head for a bit until it found the corollary thought: design UI interfaces to be workflow based instead of feature based. As developers I think we naturally componentize and abstract away our systems into sets of features: save, save all, save as, delete, editing options, undo/redo, etc. The user doesn’t break up his or her system that way at all; the user thinks “I need to get X done quickly.” That’s a very different way of thinking.
And to apply that to coding? So that I can say wonderful things like “list.last” instead of “if (list.length > 0) { list.get(list.length – 1) } else { null }”? That’s fantastic.
Not to say that it’s without problems: more methods = more testing, of course… but since you’re using TDD you wrote the tests before you created those seventy-some-odd methods, right? Right.