Что выбрать: GUI или API тесты?

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



Вопрос: Есть ли какой-то проверенное правило для того, чтобы определить, где проводить тестирование? Как понять, в каких случаях нужно выбирать уровень 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. Когда я все это объясняю, люди часто сопоставляют мой способ со своей любимой моделью пирамиды. Я не использую модели пирамид. Предпочитаю создавать модель системы, с которой работаю, а не полагаться на шаблон. Другие люди, впрочем, предпочитают модели пирамид.

Автор: Alan Richardson

Нет комментариев