Автоматизированное тестирование дыма в приложении WPF?
У нас есть приложение WPF, которое мы хотели бы запустить на нем в автоматическом режиме. Простые тесты, такие как загрузка документа, сохранение документа и т. Д., И т. Д. Мне было интересно, кто-нибудь может предложить существующие фреймворки или приложения, которые помогут с этим.
Спасибо!
2 ответа
Для тестирования фреймворков хороши как NUnit, так и MSTest. Преимущество MSTest в том, что он очень хорошо интегрируется с визуальной студией, что немного облегчает работу. (Существуют надстройки nunit для vs, но они полностью интегрированы как mstest).
С точки зрения того, как вы пишете тест, если вы написали свое приложение в соответствии с шаблоном MVVM, довольно просто заставить ваши тесты создавать и запускать ваше приложение, используя модели представлений и команды, фактически не создавая представление.
Даже если вы не использовали MVVM, надеюсь, вы по-прежнему абстрагируете свои логические слои от графического интерфейса, поэтому ваши тесты могут вызывать их без особых сложностей.
С точки зрения фактического тестирования GUI, вы можете взглянуть на среду MS UI Automation, которая должна позволить вам автоматизировать части вашего UI для запуска тестов против него. Здесь есть пост в блоге о том, как с этим работать, и статья здесь. Существуют также некоторые коммерческие структуры, которые накладывают средства автоматизации пользовательского интерфейса, чтобы сделать его немного проще. Одним из примеров является http://www.testautomationfx.com/.
Поскольку спиц-тестирование должно быть "сквозным", то я бы посмотрел на инструменты автоматического тестирования пользовательского интерфейса, такие как Test Complete, а не на модульное тестирование - создание сценария для создания виртуальной машины и запуск ваших установщиков - еще один хороший вариант. Вы говорили test должен включать установщик для вашего приложения, так как они, как правило, не охватываются модульными тестами или не используются вашими разработчиками.
Вы пытаетесь избежать того, чтобы ваши тестировщики тратили время на "безнадежные" сборки - отсюда и необходимость включать установщик.
Подумайте обо всех "дурацких" причинах, которые мешают вашей группе тестирования быть продуктивной после того, как они потратили время на установку новой сборки, - сколько из них вы можете включить в автоматизированную систему, не провалив тесты из-за изменений в приложении.
Многие люди допускают ошибку, пытаясь охватить слишком много в тесте со спицами - "глубокое тестирование", охватывающее всю вашу логику, должно проводиться в модульных тестах и / или "сюжетных тестах", а не в тесте со спицами.