Visual Studio модульное тестирование Windows Forms

Question

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

Довольно просто протестировать Winforms с ApprovalTests (www.approvaltests.com или тесты одобрения Nuget), и они совместимы с MsTest и Nunit.

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

Answer 7

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

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