Как проверить пользовательский интерфейс WPF?

Question

Используя формы win с архитектурой MVC / MVP , я обычно использовал бы класс, чтобы обернуть представление для проверки пользовательского интерфейса при использовании макетов для модели и контроллера / презентатора. Класс-оболочка сделает большинство всего в пользовательском интерфейсе наблюдаемым свойством для бегуна тестов через свойства и события.

Будет ли это жизнеспособным подходом к тестированию приложения WPF? Есть ли способ лучше? Есть ли какие-нибудь ошибки, за которыми стоит следить?

Answer 1

Что касается самого тестирования, вам, вероятно, лучше всего использовать UI Automation framework. Или, если вы хотите более гибкий и независимый от wpf / winforms / win32 / swt способ использования инфраструктуры, вы можете загрузить White из Codeplex (при условии, что вы можете использовать открытый исходный код в ваше окружение).

Для готчей; Если вы пытаетесь проверить свои представления, вы, вероятно, столкнетесь с некоторыми проблемами многопоточности. Например, если вы работаете с NUnit, тестовый прогон по умолчанию будет работать в MTA (многопоточная квартира), тогда как WPF должен работать как STA (однопоточная квартира). Mike Two действительно легко приступить к модульному тестированию WPF, но без учета проблемы с многопоточностью. У Джоша Смита есть некоторые соображения по поводу темы потоков в этой публикации , и он также указывает на эту статью Криса Хедгейта. Крис использует модифицированную версию CrossThreadTestRunner Питера Провоста для более дружественного решения проблем MTA / STA.

Answer 2

@ Мэтт Дэвид,

Пожалуйста, прочитайте документацию и посмотрите примеры кода для Microsoft CompositeWPF (он же Prism). Это проект, созданный специально для обучения работе с архитектурой MVP / MVC в тестовом режиме. Их пример приложения содержит модульные тесты для презентаторов \ контроллеров и очень крутые приемочные тесты для пользовательского интерфейса (они используют White Framework для имитации действий пользователя)

Answer 3

Вручную. Я не большой поклонник автоматизированного тестирования пользовательского интерфейса , если вы к этому стремитесь. Я не уверен насчет руководств WPF (нужно читать через ссылки aku) .. потому что они все еще укрепляются, так сказать ... WPF не стабилизировался с точки зрения «что является правильным путем». Если вы не используете одну из этих развивающихся платформ ... Я был бы консерватором w.r.t. усилие

• Проверка (автоматическая, предпочтительно TDDed) логика / презентаторы / контроллеры безжалостно. Я не защищаю неряшливость или вялость .
• Держите оболочку пользовательского интерфейса в тонусе и заставьте некоторых неприятных тестеров испытать (вручную) трещину на ней с помощью пробного тестирования - ничто так не хорошо, как «тестер из ада», когда дело доходит до интерфейсов. Соотношение усилий и выигрышей от автоматизации такого рода испытаний огромно, не улавливает все и не имеет смысла ... кроме как для умиротворения старших взлетов. Посмотрите Mgr! Без рук! пользовательские интерфейсы самотестирования! '

PS: вы можете захотеть посмотреть это (Google Talk на Lean Мэри Поппендик) .. особенно часть о том, что автоматизировать в тестировании

Answer 4

2016 Обновление: Используйте бесплатную среду TestStack.White для автоматизации тестирования пользовательского интерфейса WPF

• Project White был заброшен , но его преемник TestStack.White доступен через пакет NuGet.
• TestStack.White имеет служебные методы для запуска приложений WPF , поиск окна / элементов управления пользователя , нажатие кнопок / элементов , имитация мыши и клавиатуры событий, ожидания и т. д.

• Пример запуска приложения WPF, нажатия кнопки и проверки результатов выглядит следующим образом:

  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) построен в первую очередь с учетом «тестируемости». Сделайте это, если считаете, что это соответствует вашему типу развития.

Также здесь есть эпизод dotnetrocks , который вы можете прослушать, если вам нужна дополнительная информация о Prism в аудио.

Answer 6

Вы также можете попробовать Guia . Позволяет напрямую тестировать один пользовательский элемент управления WPF.

Answer 7

Для ознакомления с основами вы также можете посмотреть несколько коротких видео на канале 9 здесь и здесь .

Answer 8

Вы можете использовать UI Automation: http://msdn.microsoft.com/en-us/library/ms747327.aspx и http://www.telerik.com/automated-testing-tools/support/documentation/user-guide/write-tests-in-code/silverlight-test-automation/wpf-test-automation.aspx

Answer 9

Я бы также порекомендовал TestAutomationFX для простой автоматизации тестирования пользовательского интерфейса. TestAutomationFX позволяет вам работать с инструментами netAdvantage для wpf aswell, который не работает с белым и QTP. TestAutomationFX имеет простой в использовании интерфейс, он интегрируется с Visual Studio и имеет хороший рекордер для записи пользовательских событий.

Answer 10

Вместо использования автоматических тестеров вы можете создавать настоящие модульные тесты для своего графического интерфейса с помощью IcuTest .