April 1, 2010
I just published an article titled ‘Using a Service Locator to Work with MessageBoxes in an MVVM Application‘ on CodeProject. It’s one solution to the now canonical question of how to work with message boxes in an MVVM app, either WPF or Silverlight. The article gives an introduction to the Service Locator pattern, in case you are not yet familiar with that concept, and then dives into an example of how to leverage it. The end result is a simple, testable, extensible way to work with message boxes from ViewModel objects.
By the way, I found out today that I got the Microsoft MVP award again. Four years in a row! Woohoo!! 😀
March 29, 2008
A few months ago I flew out to Redmond so that I could speak at Microsoft’s WPF Bootcamp. I gave a presentation about implementing the Model-View-Whatever pattern in WPF, which was received very well by the attendees. After giving that presentation I solidified the material into my ‘Using MVC to Unit Test WPF Applications‘ article on CodeProject. This seminal work is the foundation of the structural skinning architecture seen in Podder.
The entire WPF Bootcamp 2008 was videotaped and recently published online. Karsten announced it a few days ago in this post. All of the videos and associated downloads are hosted in a Silverlight application (of course), which you can view here. NOTE: That page comes up empty for me in FireFox, so be sure to open in it Internet Explorer.
You can find my presentation under Day 3. It is called “Hello, Real World!” and runs for about one hour. I highly suggest you check out some of the other presentations, too. There were many interesting things discussed during the bootcamp.
In case you want to download the entire video file,which is quite large, you can grab them individually from this page. My video is around 330MB so it might take a while to download it, but if you’re just dying to fill up that new external hard drive… 🙂
July 14, 2007
I just published an article on CodeProject which discusses how to write unit tests for classes that depend on DispatcherTimer to get their work done.
It seemed like a pretty straightforward task when I first tried to write a unit test for functionality which uses DispatcherTimer. Wow, was I wrong! It was actually a mind-bending experience, which required me to learn a lot about how WPF’s Dispatcher and DispatcherTimer work. If you want to read more about what I learned along the way, here’s the link: http://www.codeproject.com/KB/WPF/UnitTestDispatcherTimer.aspx
July 9, 2007
My regular stream of blog posts has recently slowed to a trickle. I’ve been spending a lot of time on my project at work, and a considerable amount of that effort has gone into creating unit tests with the NUnit v2.4 framework. In this blog post I share a few tips I have learned along the way about using NUnit with WPF.
First of all, it is important to know that WPF elements must be created on a thread which uses the Single Threaded Apartment (STA) model. By default, NUnit uses worker threads with the Multithreaded Apartment (MTA) model to run your tests. If you try to create an element/control in an NUnit test you will quickly see what I mean.
When I first encountered this issue I was working on my laptop in a coffeehouse without an Internet connection. I spent far too long figuring out a solution which worked. When I got home and searched for a solution, I immediately found this blog post. That solution includes a nifty way of keeping an exception’s stack trace valid, so I ended up adopting the code in that post. Keep in mind that not all testing frameworks use MTA threads to run your tests, so this might not be a problem for people out there creating WPF elements with other unit testing frameworks.
Another point of interest for folks who create unit tests for WPF classes is that the Application.Current property will return null when a unit test executes. When your unit tests are running there is no Application instance with an active message pump churning away. If you are testing code which relies on Application.Current then you should consider using dependency injection on that class, so that your test code can inject a dummy Application instance.
For example, you might want to do something like this for the class under test:
Classes in the application would use the parameter-less constructor, and the test code would use the constructor which accepts an Application instance.
Here is a blog post which contains many useful links related to unit testing WPF code: http://mdavey.wordpress.com/2007/06/14/ui-automation/