Visual Studio Unit Тестирование форм Windows

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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

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

Здесь есть видеоролик о том, как это сделать: https://www.youtube.com/watch?v=hKeKBjoSfJ8

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

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

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

Ответ 5

Посмотрите на Джереми Д. Миллера WIP Страница вики-страниц шаблонов для рефакторинга вдохновения:)

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

Ответ 6

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

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

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

Ответ 7

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

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

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