Тестирование, управляемое данными (Data-Driven Testing)

Методология тестирования, управляемого данными (DDT) применяется в автоматизации тестирования ПО, представляет собой тестирование, выполнение и верификация которого производится на основе данных, которые хранятся в БД или любых других источниках данных.

Обычно сравнивают эталонные данные с теми, что на выходе получает система из метода (функции, программы и т.п.).

Тестирование, управляемое данными подразумевает разделение юнит тестов и данных, которые в них проверяются. Юнит тесты получают эталонные данные из некого источника и сравнивают их с результатами, полученными при тестировании объекта.

Изначально ABAP Unit не предоставляет никакого сервиса для хранения и ведения тестируемых данных, как например это делают другие фреймворки для тестирования: jUnit, nUnit. В статье пойдет речь о том как обойти это недоразумение.

В качестве подобного сервиса можно использовать контейнеры данных eCATT. Что такое eCATT и для чего он нужен можно посмотреть тут. Нас интересует один из элементов eCATT, а именно контейнер тестовых данных. Исходя из названия, становится понятно, что контейнер позволяет хранить внутри себя какие-то данные, но кроме хранения можно так же и вести (изменять) эти данные.

Рассмотрим небольшой пример, допустим, есть метод рассчитывающий тип треугольника относительно размеров его сторон, как известно из школьной программы, тип может быть следующим:

  • Равносторонний (все стороны равны)
  • Равнобедренный (хотя бы две стороны равны)
  • Разносторонний (нет равных сторон).

Создадим класс ZCL_TRIANGLE c указанными атрибутами:

triangle_attr

Метод GET_TYPE:

triangle_type

Параметры метода:

type_param

Реализация:

Как видно из примера, в случае некорректных данных вызывается исключение. В данной статье не описывается создание и использование классов исключений, при желании можете посмотреть в ранее опубликованной статье.

Статья подразумевает что вы знаете как писать юнит тесты, а если нет, добро пожаловать в введение.

Напишем сначала юнит тест, проверяющий метод без использования каталогов тестов:

new_test

Как вы можете убедиться, запустив тест (ctrl+shift+F10), он будет успешно пройден:

test_ok

Но что делать, если количество тестовых данных возрастает? Описывать множество возможных вариантов для тестирования в самом юнит тесте не корректно, т.к. объем кода в этом случае будет огромным. Тут к нам на помощь приходит методология тестирования, управляемого данными и каталог тестовых данных eCATT.

  • Создаем каталог, запустив транзакцию SECATT:

secatt

  • Определяем параметры (то из чего состоит) каталога:

cat_param

  • Далее необходимо определить сами данные, данные определяются в так называемых вариантах, по умолчанию всегда в системе есть вариант ECATTDEFAULT, его будем игнорировать в дальнейшем:

cat_variants

На данном этапе закончим с eCATT и создадим один небольшой класс, от которого будут наследоваться наши тестовые классы, в нем мы напишем метод, запускающий тестовые методы с указанным каталогом тестов.

Атрибуты:

attr_unit

У класса будет единственный метод run_variants, который используя API eCATT, будет получать тестовые данные, API реализовано в классе cl_apl_ecatt_tdc_api. Более подробное описание API можно найти официальной документации.

Параметры метода:

unit_param

Код:

Далее перепишем наш тестовый класс:

Как видно покрытие тестами возрасло, а код уменьшился на порядок. В итоге благодаря DDT и eCATT можно сильно облегчить себе жизнь в ходе тестирования, опираясь на данные, не зашитые в самом юнит тесте.

Материал данной статьи был позаимствован из следующего источника:

http://scn.sap.com/community/abap/testing-and-troubleshooting/blog/2014/02/25/data-driven-testing-with-abap-unit

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *