Пользовательский интерфейс приложения

Question

Может ли приложение пользовательского интерфейса быть проверено модулем?Давайте рассмотрим приложение с пользовательским интерфейсом, которое имеет простую форму входа.Что бы сформировать часть модульного теста для этого приложения пользовательского интерфейса.Должна ли проверка ответа бэкенда являться частью модульного теста для формы входа?

На мой взгляд, он должен включать;

1. соответствующая визуализация компонентов пользовательского интерфейса в форме.
2. включение / отключение компонентов на основе действий пользователя (пароль не может быть пустым сообщением, если пароль не введен и форма отправлена).

Существуют ли какие-либо рекомендации / правилачто следует использовать при разработке юнит-тестов для пользовательского интерфейса?Следует ли учитывать поведение приложения при модульном тестировании?

Answer 1

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

Наиболее важной частью является наличие некоторой архитектуры Model-View- younameit , поскольку только это позволяет вам изолировать пользовательский интерфейс от остальной части приложения. Тест для формы входа может быть следующим:

• Инструмент (например, White или Ranorex) имитирует пользователя, набирающего некоторую комбинацию пользователь / пароль.
• Тест проверяет (с помощью, например, насмешливого фреймворка или Typemock), что правильные методы вызываются (или не вызываются при определенных обстоятельствах).

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

НТН!
Томас

Answer 2

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

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

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

В вашем примере в идеале проверка входных данных и аутентификация должны быть отделены от графического интерфейса пользователя, поэтому вы можете выполнить их модульное тестирование (предпочтительно путем макетирования БД). Таким образом, вы можете убедиться, что вход в систему работает, как и ожидалось, для всех видов нормальных / ненормальных входов (пустой идентификатор пользователя / пароль, странные символы, очень длинный ввод, вход в систему одного и того же пользователя дважды, ...). Затем в тестах пользовательского интерфейса вам нужно всего лишь протестировать несколько распространенных тестовых примеров, чтобы убедиться, что приложение действительно работает.

Answer 3

Если ваш пользовательский интерфейс является родным графическим приложением, вы можете рассмотреть AutoIt (только для Windows), который позволяет программно щелкать любое место на экране и моделировать текст, введенный в виджет или просто на клавиатуре. прессы. Он также имеет возможность считывать цвета пикселей в указанных местах. Или вы можете использовать его, чтобы делать снимки экрана и сравнивать изображения.

Если это веб-интерфейс, вы также можете рассмотреть возможность использования xpath, чтобы определить (не графически), существуют ли элементы в сгенерированном HTML. Это не поможет вам с тем, как страницы отображаются. AutoIt также может помочь с этим, но вы не сможете выполнить один и тот же тип теста на другой платформе, если вы хотите, чтобы все пользователи со всех платформ имели доступ к вашей странице в разумных пределах.

Если ваш пользовательский интерфейс основан на консоли, рассмотрите возможность использования Expect. Я предпочитаю ожидание на основе Perl , основанное на ожидании TCL .

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