Re: Test Driving WPF

Charlie Poole <[email protected]> Tue, 5 Nov 2013 11:52:56 -0800
Newsgroups gmane.comp.programming.test-driven-development
Message-ID <CAJ+=fjj17kzERJRkWwUKrkE6jdurUXi7aQCdw_tVe+qUdiAByw@mail.gmail.com>
Nice summary. I like "mapping old experience doesn't work" ... except it's
the only kind I have. :-)

Charlie


On Tue, Nov 5, 2013 at 7:16 AM, Gishu Pillai <[email protected]> wrote:

>
>
> 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 :)
>
>  
>