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