How to test WPF user interface?

Question

Using win forms with MVC / MVP , I would usually use a class to wrap a view to test the user interface when using mocks for the model and controller / presenter. The wrapper class will make the majority in the user interface a visible property for the test runner through properties and events.

Will this be a viable approach to testing a WPF application? Is there a better way? Are there any problems requiring attention?

Answer 1

As for the testing itself, you are probably best off using a user interface automation environment. Or, if you want a more flexible and wpf / winforms / win32 / swt independent way of using the infrastructure, you can download White from Codeplex (assuming you are able to use open source in your environment).

For Goce; If you are trying to test your ideas, you are likely to run into some multithreading issues. For example, if you work with NUnit, the standard test run will work in MTA (multi-threaded apartment), while WPF should work as STA (single-threaded apartment). Mike Two really easily started unit testing WPF, but without multithreading issues. Josh Smith has some thoughts on the topic of threads in this post , and he also points to this article by Chris Hedgate. Chris uses a modified version of Peter Provost CrossThreadTestRunner for a more friendly solution to MTA / STA problems.

Answer 2

@Matt David,

Read the documentation and see code samples for Microsoft CompositeWPF (aka Prism). This is a project created specifically for teaching methods of working with the MVP / MVC architecture in test mode. Their sample application contains unit tests for presenters \ controllers and very cool acceptance tests for the user interface (they use the White framework to simulate user actions)

Answer 3

Manually. I'm not a big fan of automated user interface testing, if that's what you get. I'm not sure about the WPF manual (you need to read through the aku links) .. because they are still hardening, so to speak ... WPF has not stabilized in terms of "that this is the right way." If you are not using one of these evolving frameworks. I would be a conservative wrt effort

• Testing (automated, preferably TDDed) logic / presenters / controllers ruthlessly. I am not a supporter of negligence or lethargy.
• Keep the user interface thin and get some nasty testers to go crack (manual) on it with exploratory tests - nothing is as good as a “tester from hell” when it comes to user interfaces, Efforts: gain from automation of this kind The testing is huge, it won’t catch everything and it makes no sense ... except to pacify the higher "Look Mgr". No hands! self-monitoring user interfaces!

PS: you can watch it (Mary Poppendieck Google Talk on Lean) .. especially the part about what to automate in testing

Answer 4

Update 2016: Use the free TestStack.White framework to automate testing of the WPF user interface.

• Project White has been abandoned , but its successor TestStack.White is available through the NuGet package.
• TestStack.White contains utility methods for launching WPF applications , searching for window / user controls , pressing buttons / elements , simulating mouse and keyboard events, waiting , etc.

• An example that launches a WPF application, clicks a button, and checks the result, looks like this:

  using TestStack.White; using TestStack.White.UIItems; using TestStack.White.Factory; [TestMethod] public void TestDoSomething() { //Opens the app var app = Application.Launch("MyApp.exe"); //Finds the main window (this and above line should be in [TestInitialize]) var window = app.GetWindow("My App Window Title", InitializeOption.NoCache); //Finds the button (see other Get...() methods for options) var btnMyButton = window.Get<Button>("btnMyButtonWPFname"); //Simulate clicking btnMyButton.Click(); //Gets the result text box //Note: TextBox/Button is in TestStack.White.UIItems namespace var txtMyTextBox = window.Get<TextBox>("txtMyTextBox"); //Check for the result Assert.IsTrue(txtMyTextBox.Text == "my expected result"); //Close the main window and the app (preferably in [TestCleanup]) app.Close(); } 

Answer 5

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

There's also an episode of dotnetrocks that you could listen to if you need more information about Prism in audio.

Answer 6

For the basics, you can also watch a few short videos on Channel 9 here and here .

Answer 7

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

Answer 8

This will work just fine, easier than with winning forms.

Check out the "WPF Application Quality Guide", it tests a lot of the WPF interface. Also don't forget the AutomationPeer class.

Answer 9

Definitely look at TestAutomationFX.com. You can invest (well, I did) a lot of time trying to capture / record events with White. (At the beginning of my quest, I ignored a message or two in other places that referred to it).

I, of course, second, other points, about the best type of testing, which is not user interface testing.

But if someone is going to do something automated in the user interface to get around the flaws in other types of testing, TAFX seems like the fastest route there.

Answer 10

Try Ranorex V2.0 to automate WPF. With RanoreXPath and Ranorex repository identification code, you can completely separate from identification information. Ranorex also provides a capture / playback editor based on RanoreXPath objects.

Answer 11

Instead of using automated testers, you can create real unit tests for your GUI with IcuTest .

Answer 12

I would recommend TestAutomationFX also for easy automation of ui testing. TestAutomationFX allows you to work with netAdvantage tools for wpf, as well as work with white and QTP. TestAutomationFX has an easy-to-use interface, it integrates with visual studio and has a good recorder for recording custom events.

Answer 13

You can use user interface automation: http://msdn.microsoft.com/en-us/library/ms747327.aspx and http://www.telerik.com/automated-testing-tools/support/documentation/user-guide /write-tests-in-code/silverlight-test-automation/wpf-test-automation.aspx

Answer 14

Since the coded user interface infrastructure expires after Visual Studio 2019 ( legacy coded user interface ), Microsoft recommends Appium with WinAppDriver for testing Windows applications (desktop and UWP).

Here is a brief description of working with WinAppDriver:

• download and install WinAppDriver:

  WinAppDriver Release

• run WinAppDriver:

  C: \ Program Files (x86) \ Windows Application Driver \ WinAppDriver.exe

• create a new unit testing project Visual Studio 2019 (.NET Framework)

• add NuGet package: Appium.WebDriver

• add a new DesktopSession class:

  public class DesktopSession { protected const string WindowsApplicationDriverUrl = "http://127.0.0.1:4723"; private const string NotepadAppId = @"C:\Windows\System32\notepad.exe"; protected static WindowsDriver<WindowsElement> session; protected static WindowsElement editBox; public static void Setup(TestContext context) { // Launch a new instance of Notepad application if (session == null) { // Create a new session to launch Notepad application var appCapabilities = new DesiredCapabilities(); appCapabilities.SetCapability("app", NotepadAppId); appCapabilities.SetCapability("platformName", "Windows"); appCapabilities.SetCapability("deviceName ", "WindowsPC"); session = new WindowsDriver<WindowsElement>(new Uri(WindowsApplicationDriverUrl), appCapabilities); Assert.IsNotNull(session); Assert.IsNotNull(session.SessionId); // Set implicit timeout to 1.5 seconds to make element search to retry every 500 ms for at most three times session.Manage().Timeouts().ImplicitlyWait(TimeSpan.FromSeconds(1.5)); // Keep track of the edit box to be used throughout the session editBox = session.FindElementByClassName("Edit"); Assert.IsNotNull(editBox); } } public static void TearDown() { // Close the application and delete the session if (session != null) { session.Close(); try { // Dismiss Save dialog if it is blocking the exit session.FindElementByName("Nicht speichern").Click(); } catch { } session.Quit(); session = null; } } [TestInitialize] public void TestInitialize() { // Select all text and delete to clear the edit box editBox.SendKeys(Keys.Control + "a" + Keys.Control); editBox.SendKeys(Keys.Delete); Assert.AreEqual(string.Empty, editBox.Text); } } 

• Change code from class UnitTest1

  [TestClass] public class UnitTest1 : DesktopSession { [TestMethod] public void EditorEnterText() { Thread.Sleep(TimeSpan.FromSeconds(2)); editBox.SendKeys("abcdeABCDE 12345"); Assert.AreEqual(@"abcdeABCDE 12345", editBox.Text); } [ClassInitialize] public static void ClassInitialize(TestContext context) { Setup(context); } [ClassCleanup] public static void ClassCleanup() { TearDown(); } } 

• run your test

(sample code is mostly copied from WinAppDriver.NotepadTest ).

Instruments:

• WindowsAppDriver UI Recorder

  Download the WinAppDriver repository and collect WinAppDriverUIRecorder.sln in the tools \ UIRecorder subdirectory.

  Introducing WinAppDriver UI Recorder

• inspect.exe: Windows SDK required (see C: \ Program Files (x86) \ Windows Kits \ 10 \ bin)

Other links:

WinAppDriver with or without Appium

Appium