Using win forms with an MVC/MVP architecture, I would normally use a class to wrap a view to test the UI while using mocks for the model and controller/presenter. The wrapper class would make most everything in the UI an observable property for the test runner through properties and events.

Would this be a viable approach to testing a WPF app? Is there a better way? Are there any gotchas to watch out for?

+7  A: 

@Matt David,

Please read documentation and take a look at the code samples for Microsoft CompositeWPF (aka Prism). It's a project created specifically to teach how to deal with MVP/MVC architecture in test-driven manner. Their sample application contains unit tests for presenters\controllers and very cool acceptance tests for UI (they use White framework to simulate user actions)

Before you launch into using White you should know that it doesn't seem to work that well (if at all) on x64.
Ade Miller

It will work just fine, easier than with win forms.

Check "WPF Application Quality Guide", it has quite a bit on testing WPF interface. Also don't forget AutomationPeer class.

+4  A: 

Manually. I'm not a big fan of automated UI testing if that is what you're getting at. I'm not sure about the WPF guidances (need to read thru aku's links).. because they are still solidifying so to speak... WPF has not stabilized from the point of 'what is the right way'. Unless you're using one of these evolving frameworks.. I'd be conservative w.r.t. effort

  • Test (Automated preferably TDDed) the logic/presenters/controllers ruthlessly. I'm not advocating sloppiness or lethargy.
  • Keep the UI skin thin and get some nasty testers to go have a (manual) crack at it with exploratory testing - nothing is as good as a 'tester from Hell' when it comes to UIs. The effort : gain ratio from automating this kind of testing is huge, doesn't catch everything and doesn't make sense... except to pacify the higher ups 'Look Mgr! No hands! self-testing UIs!'

PS: you may want to watch this (Mary Poppendieck's Google Talk on Lean).. especially the part about what to automate in testing

Manual testing doesn't fully replace automatic (or vice a versa). The purpose of automated testing is not to find errors, it's to make sure that new changes don't break already tested old features.
I think I left out an important word up there :) in the first bullet.
You forgot regression tests - it is a real pain for a manual tester to run through hundreds of forms just to check for some basic stuff which could be easier done automatic. Better spare the tester this tedious stuff, so he can concentrate on the nasty testing.
I don't like UI regression tests cycles. These are the tiny-easy-to-fix things that don't break that often, e.g. the tab order is wrong. manually test the UI once thoroughly and let it be. wont break unless someone goes in and changes the UI.. what's *basic stuff that can be automated
+2  A: 

Prism (Composite WPF) is built primarily keeping "Testability" in mind. Go for it, if you think it suits your kind of development.

Also here is the the dotnetrocks episode you could listen to, if you need more information on Prism in audio.


For the basics, you can also check out a few short videos on channel9 here and here.

+12  A: 

Hi, Matt

As for the testing itself, you're probably best off using the UI Automation framework. Or if you want a more fluent and wpf/winforms/win32/swt-independent way of using the framework, you could download White from Codeplex (provided that you're in a position to use open source code in your environment).

For the gotchas; If you're trying to unit test your views, you will probably run in to some threading issues. For instance, if you're running NUnit the default testrunner will run in MTA (Multi-Threaded Appartment), while as WPF needs to run as STA (Single-threaded Appartment). Mike Two has a real easy getting-started on unit testing WPF, but without considering the threading issue. Josh Smith has some thoughts on the threading issue in this post, and he also points to this article by Chris Hedgate. Chris uses a modified version of Peter Provost's CrossThreadTestRunner to wrap the MTA/STA issues in a bit more friendly way.

Kjetil Klaussen
re CTTR: NUnit 2.5 has STATThreadAttributeAlso definitely evaluate TestAutomationFX - its really nice (not affiliated, just a customer). Also looked at White - but it didnt seem to have a recording story in the same ballpark.
Ruben Bartelink
Ah, just saw http://stackoverflow.com/questions/58340/how-to-test-a-wpf-user-interface/341120#341120, LOL!
Ruben Bartelink

Definitely look at TestAutomationFX.com. One can invest (OK, I did) a lot of time trying to capture / record events with White. (At the start of my quest I ignored the post or two in other places referring to it).

I of course second the other points about the best type of testing not being UI testing.

But if someone is going to do something automatable in the UI to get around shortcomings in other types of testing coverage, TAFX seems the quickest route there.

Ruben Bartelink

Try Ranorex V2.0 for WPF automation. With RanoreXPath and Ranorex repository test automation code could be completely seperated from identification information. Ranorex also provides a capture/replay editor based on RanoreXPath objects.


Rather then using automated testers, you can create true unit tests for your GUI with IcuTest.

+1  A: 

You can also try out Guia. It allows you to directly unit test single WPF UserControls.


I would recommend TestAutomationFX as well for simple automation of ui testing. TestAutomationFX lets you work with netAdvantage tools for wpf aswell , which doesnt work with white and QTP. TestAutomationFX has a easy to use interface , it integrates with visual studio and has a good recorder for recording user events.