Automated smoke testing of a WPF App? [closed]

Question

We've got a WPF app we'd like to run automated smoke tests on it. Simple tests like load document, save document, etc, etc. I was wondering if anyone could suggest existing frame works or applications that would help with that.

Thanks!

Answer 1

For testing frameworks both NUnit and MSTest are good. MSTest does have the advantage that it integrates very will with visual studio, so that makes things a bit easier. (There are nunit addins available for vs, but they are quite as fully integrated as mstest).

In terms of how you write the test, if you have written you app according to the MVVM pattern it's pretty simple to have your tests create and run your app using the view models and the commands without actually creating a view.

Even if you haven't used MVVM, hopefully you've still abstracted your logic layers away from your gui, so your tests can call into them without too much difficulty.

In terms of actual GUI testing, you can take a look at the MS UI Automation framework which should allow you to automate parts of your UI to run tests against it. There's a blog post here about how to get going with that, and an article here. There are also some commercial frameworks that overlay the UI automation stuff to make it a bit easier. One example is testautomationfx.

Answer 2

As a spoke test should be “end to end”, then I would look at automated UI testing tools like Test Complete, rather than unit testing tools – scripting the creation of a VM and then run yours installers is another good option.. You spoke test should include the installer for your app, as they tend not to be covered by unit tests, or used by your developers.

You are trying to avoid your testers spending time on “hopeless” builds – hence the need to include the installer.

Think of all the “daft” reasons that stops your test team being productive after they have spent time installing a new build – how many of these can you include in an automated system without having tests fail due to changes in the app.

A lot of people make the error of trying to cover too much in a spoke test – “deep testing” that covers all your logic should be in unit tests and/or “story tests” not your spoke test.