I know, WinForms is soooooo 2006, but we will not start WPF for real until there are non-beta tools available (orcas/ blend).

Jeremy has a post few a few days back on writing testable win forms apps. My answer is a simple one. Minimize the stuff in the “hard to test” user controls.

• * User Controls/ Composite user controls often - implement some interface. The purpose of this interface is partitioning, NOT for someone else to extend it per se.
• Let’s say we are writing a “trade blotter”, our interface might have methods like:
• Trade[] GetSelectedTrades();
• void MarkTradeInEdit(int tradeId);
• void SelectTrades(int[] tradeIds);
• etc.
• * We externalize the “automation” of the calls to the UI using 2 kinds of “commands”.
• Presenter Commands - their job is to intersperse calls to the UI interface and calls to the “Background Commands”.
• Background Commands - the commands that have nothing to do with the view. These commands often act agains services like:
• BookTradeCommand
• SaveTradeCommand
• GetTradeCommand
• * The view has a reference to s single Presenter that it gives “named gestures”. If someone wants to Click a button and ask to load some trade data, we say something like:
• presenter.HandleGesture(”loadTradeClick”); 
• * The Presenter ”wires together” buckets of commands to a View. This means that for any named gesture, you can “wire it” to some command in the presenter’s bucket. If the View is some winforms implementation of ITradeBlotter, so be it, the commands will automate it. If it is a mock ITradeBlotter, so be it. In the past Spring has been the main device to do this all and it has worked out great - the wiring together commands to named gestures.

Generally, this model is very simple. You can have some developers go off and write a UI component according to some interface you talk about. This helps the team decide what the UI component should do. Before, after or during that process other people can be writing commands to automate the UI via some commands that just talk to an interface that is their view. You get extreme reuse out of the “background commands” that simply do units of work. Whenever you need to change a behavior, add a behavior, etc, you can often just create some new commands and the view stays the same. It is all very very testable in this case. The big win of testability is one, flexability is another, and the ability to work well in a team environment - partitioning the work is a huge win as I see it.

There is lots more I could say about all this. This is certainly NOT 100% automation of the UI tested. It has been in the past “the best we could get”. I would love to have a more complete answer, but this has proven useful to me. I have yet to see a more testable UI development methodology.

-Chris

 

Comment on this post below

You must be logged in to post a comment.

You can leave a response, or trackback from your own site.