Re: Test Driving WPF

At present, I'm simply trying to build an understanding of good TDD with WPF.  I'd love to find a tutorial for Caliburn.Micro that demonstrates test-driving.  I think the prerequisite for this is to push these classes into class library projects, and I'm not seeing that out there.

(Eventually I want to make a multipage form, but just anything to get me understanding is good now.  I have a vague sense that Caliburn represents a way of thinking I'm not accustomed to.  Reading more now.)
 

Alan Baljeu


________________________________
 From: Gishu Pillai <[email protected]>
To: [email protected] 
Sent: Tuesday, November 5, 2013 10:16:02 AM
Subject: Re: [TDD] 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 :)