Перевод статьи «Should I test at the GUI Level or the API Level?» от UncaughtException.
Где тестировать? Если вы можете изолировать какой-то функциональный элемент, то начните с него и протестируйте его с особой тщательностью. Далее определите, в каких местах системы интегрируются и как. От последнего зависит, насколько тщательно нужно тестировать интеграцию.
Вопрос: Есть ли какой-то проверенное правило для того, чтобы определить, где проводить тестирование? Как понять, в каких случаях нужно выбирать уровень GUI, а в каких API?
Ответ: Не думаю, что есть какой-то универсальный совет. Но я постараюсь описать, как я рассуждаю, когда решаю, где проводить тесты.
Чтобы выбрать между GUI и API тестом, я должен понять:
- Что я собираюсь тестировать?
- Могу ли я изолировать тестируемую функцию на одном из «уровней»?
- Ориентируйтесь на слово «изолировать». На мой взгляд, это и есть то самое правило номер один, про которое вы спрашиваете.
- Тщательно протестируйте функции, которые можете изолировать
- Далее тщательно протестируйте интеграцию для уникальной изолированной функции
- Протестируйте интеграцию настолько тщательно, насколько того требует реализация
- Протестируйте интеграцию на предмет непредсказуемого поведения
- Менее подробно протестируйте моменты, в которых системы совпадают при интеграции
Например, в системе есть функция «создать пользователя», причем:
- В GUI она является элементом интерфейса администратора
- В API ее можно вызвать с помощью запроса в архитектуре REST
Выходит, мне нужно тестировать эту функцию на обоих уровнях, так как она не изолирована. Теперь я спрашиваю себя: что именно и насколько подробно нужно тестировать на каждом уровне?
Быть может, я решу вообще особо не тестировать в GUI, если GUI вызывает REST API, потому что я могу моделировать эту ситуацию в виде двух (как минимум) взаимодействующих систем. Система GUI и система API.
Далее я тщательно тестирую на уровне API те функции, которые изолированы в API, и менее тщательно – функции, находящиеся на пересечении GUI и API.
Также мне нужно протестировать функции, уникальные для GUI. Например, если GUI позволяет делать ajax-запросы, то тестировать эту возможность следует на уровне GUI.
В зависимости от разработки может оказаться, что ajax-запросы уже проверены с помощью unit-тестов JavaScript. Однако тесты не были интегрированы в страницу браузера или не проводились во всех браузерах и операционных системах, в которых используется GUI. Поэтому, исходя из используемых библиотек, я провожу кроссбраузерное тестирование и тесты в разных ОС.
Если GUI и API используют разные точки входа, придется тестировать оба пути. Здесь нужно проверить серверный код до того момента, когда будет обнаружен общий для двух интерфейсов код. При условии, что у REST API и серверной части GUI есть этот общий код. Также в этот момент нужно понять, насколько unit-тесты покрывают этот общий код.
Итак, мое правило можно записать в виде списка действий:
- Постройте модель системы так, чтобы вы могли определить точки интеграции и общие «изолированные» функции;
- Протестируйте изолированную функцию на самых нижних уровнях, которые вам доступны;
- По очереди переходите к более высоким (или «одноранговым») уровням интеграции и абстракции и рассмотрите систему с точки зрения интеграции систем;
- Ищите уникальные функции, присущие более высоким (или «одноранговым») уровням абстракции. Их надо тестировать именно здесь:
- Если вы проверяете некий функционал изолированно, создавая mock-объекты интегрированных систем, то вам может понадобиться оценить технические риски и решить, нужно ли будет использовать эту функцию после интеграции, и если да, то как часто.
По-другому этот процесс можно представить вот так:
- Создайте несколько пересекающихся моделей системы;
- Проверьте тестовое покрытие моделей системы;
- Проверьте тестовое покрытие потоков, идущих через разные модели системы;
- Рассмотрите технические риски, связанные с реализацией и средой, в которой работает система;
PS. Когда я все это объясняю, люди часто сопоставляют мой способ со своей любимой моделью пирамиды. Я не использую модели пирамид. Предпочитаю создавать модель системы, с которой работаю, а не полагаться на шаблон. Другие люди, впрочем, предпочитают модели пирамид.