Автоматическое дымовое тестирование приложения WPF?[закрыто]

Question

У нас есть приложение WPF, и мы хотели бы провести для него автоматические дымовые тесты.Простые тесты, такие как загрузка документа, сохранение документа и т. д. и т. п.Мне было интересно, может ли кто-нибудь предложить существующие фреймворки или приложения, которые могли бы в этом помочь.

Спасибо!

Answer 1

Для тестирования фреймворков хороши как NUnit, так и MSTest.Преимущество MSTest заключается в том, что он очень хорошо интегрируется с Visual Studio, что немного упрощает задачу.(Для vs доступны дополнения nunit, но они так же полностью интегрированы, как и mstest).

Что касается того, как вы пишете тест, если вы написали приложение в соответствии с МВВМ шаблон, довольно просто заставить ваши тесты создавать и запускать ваше приложение, используя модели представлений и команды, без фактического создания представления.

Даже если вы не использовали MVVM, мы надеемся, что вы все равно абстрагировали свои логические уровни от графического интерфейса, чтобы ваши тесты могли обращаться к ним без особых затруднений.

Что касается фактического тестирования графического интерфейса, вы можете взглянуть на Автоматизация пользовательского интерфейса MS framework, который должен позволить вам автоматизировать части вашего пользовательского интерфейса для запуска тестов.Есть запись в блоге здесь о том, как с этим справиться, и статья здесь.Существуют также некоторые коммерческие фреймворки, которые накладываются на автоматизацию пользовательского интерфейса, чтобы сделать ее немного проще.Одним из примеров является testautomationfx.

Answer 2

Поскольку периферийное тестирование должно быть «сквозным», я бы посмотрел на инструменты автоматического тестирования пользовательского интерфейса, такие как Test Complete, а не на инструменты модульного тестирования — еще один хороший вариант — написать сценарий создания виртуальной машины и затем запустить свои установщики.Ваш разговорный тест должен включать установщик вашего приложения, поскольку они, как правило, не охватываются модульными тестами и не используются вашими разработчиками.

Вы пытаетесь не допустить, чтобы ваши тестировщики тратили время на «безнадежные» сборки — отсюда и необходимость включения установщика.

Подумайте обо всех «глупых» причинах, которые мешают вашей команде тестировщиков работать продуктивно после того, как они потратили время на установку новой сборки — сколько из них вы можете включить в автоматизированную систему, не допуская сбоев тестов из-за изменений в приложении.

Многие люди совершают ошибку, пытаясь охватить слишком много в устном тесте — «глубокое тестирование», охватывающее всю вашу логику, должно проводиться в модульных тестах и/или «исторических тестах», а не в устном тесте.