Тестирование сложных объектов

Question

У меня есть форма на C # с различными элементами управления.Форма управляет текущим процессом, и для правильной работы программы необходимо учитывать множество аспектов.

Каждая часть может подвергаться модульному тестированию (например, загрузка некоторых коэффициентов, диагностика)но я часто сталкиваюсь с проблемами, которые лучше всего описать на примере:

"Если я нажму здесь, затем здесь, затем измените это, затем снова откройте форму, затем нажмите здесь, она падает иливыдает ошибку "

Я старался изо всех сил использовать общие организационные идеи кода (наследование, DRY, разделение проблем), но, кажется, никогда не было способа проверить каждый отдельный путь, и неизбежноформа с несколькими элементами управления будет иметь огромное количество способов выполнения.

Что я могу прочитать (желательно онлайн), чтобы решить этот тип проблемы, и есть ли (неуниверсальный) термин для этого.Это не конкретная проблема, которая у меня возникает, особенно та, которая возникает у меня, особенно с WinForms.

Answer 1

Каждый из этих принципов (наследование, СУХОЙ, разделение интересов), конечно, не является гарантированным рецептом для высококачественного кода.Если вы используете свой унаследованный метод DRY для деления на ноль, то вы все равно делаете что-то не так.

Мой совет для трудно отслеживаемых ошибок: ведение журнала!Записать внутреннее состояние переменных в ключевые моменты шагов пользователя, чтобы воспроизвести проблему.

Answer 2

Вы пытаетесь провести приемочное тестирование, а не юнит. Полезно проверить, все ли кирпичи вашей системы правильно соединены вместе. Но сами кирпичи должны быть протестированы с тестами .

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

Убедившись в своих подразделениях, проведите несколько функциональных / интеграционных / приемочных тестов, чтобы убедиться, что ваши подразделения хорошо играют вместе.

Для модульного тестирования вы можете использовать NUnit или встроенную тестовую систему. Для приемочных испытаний смотрите FITnesse или ищите коммерческие продукты.

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

Answer 3

Я столкнулся с этой проблемой (протестировать каждый путь) с Windows Forms.Но после перехода на WPF, Silverlight проблема решена.Используйте MVVM вместе с шаблоном команд (в основном, гарантируя, что у вас нет кода в файлах с выделенным кодом).Убедитесь, что у вас есть отдельные классы ответственности.В своих модульных тестах вы можете смоделировать каждый сценарий, включая нажатие кнопок, и вы сможете проверить все возможные пути.Я не уверен, как вы сможете использовать MVVM и шаблон команд в WinForms.Но я, Google, обязательно предоставлю вам ответы на некоторые вопросы.

Answer 4

Я бы попытался отобразить обычные рабочие процессы пользовательского интерфейса (с небольшими отклонениями, возможно, используя «foreach» в контрольных списках, чтобы представить, что вы - спам везде и меняете материал) в качестве модульных тестов.

Iне будет заходить так далеко (нажмите на (x, y)), но будет больше событий запуска, таких как "txtUsername_Focused", "txtUsername_TextChanged", "btnBack_Click", "btnForward_Click", "btnSave_Submit", конечно, с некоторой обработкой, если вы получаете другуюв результате отображаются формы.