Re: Test Driving WPF

Having difficulty visualizing what you're trying to build.

Here's whats worked for me...
- Use MVVM because otherwise you'd be fighting WPF most of the time..
Windows Forms and WPF are different beasts .. so mapping old experience
mostly doesn't work.
- ViewModel: Your view model should hold the state for the view. This means
that you can trigger it via changing "Properties" or executing 'Commands'
and inspect the results. (State based testing)
- Model: You can verify whether the view model invokes the right methods on
the backing model - Use state/interaction based style as you find
comfortable. You can usually test the Model independently because it
generally has no dependencies on either the VM or the View.
- View: I'm mostly okay with not testing this at all because usually it
should just contain "Bindings". Frameworks like Caliburn use convention to
auto-magically bind view controls to VM properties/commands. Minimize any
code in the code-behind

- Finally you'll still have tests where you need to test interaction
between multiple viewmodels or you just had to write some code in the
code-behind (because the MVVM way was too hard - e.g. testing default
focus) - I've had some amount of success with white (not called
teststack.white) which drives GUIs on Windows.

Special mentions:
Bypass the dispatcher - this is a 'golden rule' of windows GUI - a UI
element should only be accessed from the thread on which it was created.
This means that once you're done doing the heavy lifting on a worker
thread, you need to channel the UI updation back on to the main/UI thread.
You usually do this by saying UIControl.Dispatcher.Invoke() / BeginInvoke()
In your tests, there won't be a UI Thread - so you need to fake this and
make it just a Sync Invoke()

HTH
Gishu

PS: It can be done :)