Объекты испытательного комплекса
У меня есть форма C# с различными средствами управления на нем. Форма управляет продолжающимся процессом, и существуют многие, много аспектов, которые должны быть правильными, чтобы программа работала правильно.
Каждая часть может быть протестированной единицей (например, загружая некоторые коэффициенты, таща некоторую диагностику), но я часто сталкиваюсь с проблемами, которые лучше всего описаны с примером:
"Если я щелкаю здесь, затем здесь, затем изменяю это, затем вновь открыл форму, затем щелкните здесь, она разрушает или производит ошибку"
Я старался изо всех сил использовать общий код организационные идеи (наследование, DRY, разделение проблем), но никогда, не кажется, существует способ протестировать каждый путь, и неизбежно, форма с несколькими средствами управления будет иметь огромное количество способов выполниться.
Что может я читать (предпочтительно онлайн), который обращается к этому виду проблемы и является там (неуниверсальным) термином для него. Это не определенная проблема, которую я имею, но тот, который приближается ко мне, особенно с WinForms.
4 ответа
Вы пытаетесь провести приемочное тестирование, а не unit. Полезно проверить, все ли блоки вашей системы правильно соединены вместе. Но сами кирпичи следует тестировать с помощью unit -тестов.
Итак, если у вас есть функция, которая принимает некоторые коэффициенты и строит диаграмму, протестируйте ее со всех сторон отдельно от графического интерфейса. Дайте ему все возможные крайние случаи коэффициентов и координат тестовых точек, которые он возвращает. Это была всего одна единица, их будут десятки, сотни или тысячи.
Убедившись в правильности своих юнитов, проведите несколько функциональных / интеграционных / приемочных тестов, чтобы убедиться, что ваши юниты хорошо работают вместе.
Для модульного тестирования вы можете использовать NUnit или встроенную тестовую систему. Для приемочных испытаний обратитесь к FITnesse или поищите коммерческие продукты.
И чтобы получить представление о том, как разделить приложение на блоки, прочтите о MVC и аналогичных архитектурных решениях.
Каждый из этих принципов (наследование, DRY, разделение проблем), конечно, не является гарантированным рецептом высококачественного кода. Если вы используете унаследованный и DRY-метод для деления на ноль, то вы все равно делаете что-то не так.
Мой совет для трудноотслеживаемых ошибок: логирование! Записывайте внутреннее состояние переменных в ключевых точках шагов пользователя, чтобы воспроизвести проблему.
Я столкнулся с этой проблемой (проверка каждого пути) в Windows Forms. Но после перехода на WPF, Silverlight проблема была решена. Используйте MVVM вместе с командным паттерном (в основном гарантируя, что у вас нет кода в code-behind файлах). Убедитесь, что у вас есть классы с единой ответственностью. В ваших модульных тестах вы можете моделировать все сценарии, включая нажатие кнопок, и вы сможете проверить все возможные пути. Я не уверен, как вы сможете использовать MVVM и командный паттерн в WinForms. Но гугл обязательно даст вам ответы.
Я бы попытался отобразить общие рабочие процессы пользовательского интерфейса (с небольшими отклонениями, возможно, используя «foreach» в контрольных списках, чтобы представить, что вы пользователь, рассылающий спам повсюду и меняющий материал) в виде модульных тестов.
Я бы не стал заходить так далеко (щелкните по (x, y)), но больше событий срабатывания, таких как «txtUsername_Focused», «txtUsername_TextChanged», «btnBack_Click», «btnForward_Click», «btnSave_Submit», конечно, с некоторой обработкой если в результате отображаются разные формы.