Re: [TDD] 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
To: testdrivendevelopment@...
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 :)
|
