Визуальная студия тестирования Windows форм

мы работаем над проектом в Visual Studio 2008 с. Мы используем встроенный пакет тестирования, поставляемый с ним (Microsoft.VisualStudio.TestTools.UnitTesting namespace). Оказывается, к нашему огорчению, большая сложность (и, следовательно, ошибки) закодированы в наш UI-слой. В то время как наши модульные тесты делают достойную работу по покрытию нашего бизнес-уровня, наш уровень пользовательского интерфейса является постоянным источником раздражения. В идеале мы хотели бы также провести юнит-тест. Кто-нибудь знаете хороший "совместимый с Microsoft" способ сделать это в visual studio? Будет ли это вводить какой-то конфликт для "смешивания" фреймворков модульного тестирования, таких как nUnitForms С вещами Microsoft? Есть ли какие-либо очевидные медвежьи ловушки, о которых я должен знать с формами модульного тестирования?

7 ответов


вы должны выполнить рефакторинг интерфейса, так что интерфейс не нужны никакие тестирования. UI должен содержать минимальную или нулевую бизнес-логику. Существует много моделей, которые касаются этой проблемы. Мартин Фаулер имеет очень хорошую статью, которая многое объясняет об этих шаблонах:http://martinfowler.com/eaaDev/uiArchs.html

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

Примечание: есть инструмент, который может быть использован для автоматизации тестирования пользовательского интерфейса. Силктест приходит мне на ум. Но я бы не стал их использовать, если бы это было возможно.


Это все хорошо и хорошо для регулярного модульного тестирования приложений ... но если вы создаете пользовательские элементы управления, которые нуждаются в модульных тестах для поведения и состояний элемента управления, ему также нужна платформа модульных тестов. NUnitForms может быть ответом для вас - лично мне нужно проверить себя.


Я использую пассивную архитектуру представления, как описано здесь http://martinfowler.com/eaaDev/PassiveScreen.html

в основном переместите весь свой код в формах в отдельный класс под названием xxxUI. Затем форма реализует интерфейс IxxxUI и предоставляет все, что нужно классу xxxUI. Вероятно, вы можете упростить вещи и объединить работу с несколькими элементами управления в один метод.

поток затем идет пользователь нажмите на кнопку. Кнопка вызывает метод для соответствующего класса UI. Передача любых необходимых параметров. Метод класса UI изменяет модель. Затем с помощью интерфейса обновляет пользовательский интерфейс.

для модульного тестирования у вас есть тестовые или фиктивные классы реализуют интерфейсы и регистрируются с классами UI. Вы можете заставить эти тестовые классы запускать любой тип ввода и реагировать соответствующим образом. Обычно у меня есть списки последовательностей, которые делают что-то в точном порядке. (Нажмите, нажмите, прокрутки, тип Б и т. д.).


довольно легко протестировать Winforms с помощью ApprovalTests (www.approvaltests.com или тесты утверждения nuget), и они совместимы с MsTest, а также с Nunit.

есть видео вот как нужно делать: https://www.youtube.com/watch?v=hKeKBjoSfJ8

но процесс прост. 1) создайте форму, которую вы хотите протестировать в состоянии, которое вы хотите проверить. 2) вызов WinFormApprovals.Проверить (форма)

ApprovalTests использует парадигму golden master для захват экрана результат. если вам нравится, просто переименуйте файл .одобрено и испытание пройдет.

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


Проверьте WIP Джереми Д. Миллера Шаблоны презентаций wiki страница для рефакторинга вдохновения :)

Миллер пишет книгу, и, похоже, это будет обязательным для такого рода вещи.


Я использовал NUnitForms, когда дело доходит до тестирования моих собственных элементов управления UI с хорошими результатами! Я бы согласился с другими в рефакторинге, если вы используете стандартные (или хорошо протестированные) элементы управления UI.

Если основное внимание уделяется тестированию фактических элементов управления, я бы использовал NUnitForms, поскольку он может быть расширен для поддержки ваших новых элементов управления. Во всяком случае, если вы не будете привлекать ручное тестирование, вам понадобится lib, который может выполнять анализ отображаемого конечного результата на основе изображений.

Я пробовал TestComplete для этого, но я думал, что это слишком дорого, так как я мог бы кодировать аналогичный lib только для сравнения изображений в c#. Поэтому мой план состоял бы в том, чтобы проверить элементы управления отдельно, а затем рефакторировать пользовательский интерфейс, Как упоминалось выше.


для тестирования уровня пользовательского интерфейса следует использовать Microsoft Coded UI. Это включает в себя написание (или запись) тестов, имитирующих действия, которые выполнял бы пользователь, и написание инструкций assert для обеспечения правильного вывода.

конечно, это, возможно, не модульное тестирование, потому что трудно создать действия с переднего конца, которые тестируют одну единицу работы и не являются заменой для другого модульного тестирования. Я согласен также с тем, что бизнес-логика front end должна быть как можно тоньше. Тем не менее, это заполнит любые пробелы, где ваши модульные тесты не охватывают. Надеюсь, только небольшие единицы работы не будут охвачены модульными тестами, так что закодированные тесты UI поймают оставшиеся непроверенные единицы.

закодированный пользовательский интерфейс встроен в последние версии Visual Studio Premium. Я предлагаю вам не просто использовать функции записи, но вместо того, чтобы научиться писать тесты самостоятельно, так как это дает вам большую гибкость.