Привет Всем !

Хотел бы поделится инструментом для юнит тестирования, который разработали я и мои коллеги для внутреннего использования. Инструмент предназначен для упрощения загрузки данных для юнит тестов. Мы сейчас ведем большой проект и приходится готовить большое количество табличных данных, например, выборки из BKPF/BSEG/BSET. Проверяемый код тоже обычно возвращает сложные структуры или таблицы (которые надо сверить с ожидаемыми).

Загрузчик данных

Хардкод подобных данных прямо в юнит тесте - не вариант - слишком много кодить, сложно поддерживать и расширять тесты, ужасная читабельность. Поэтому мы решили разработать инструмент, который бы загружал данные из текстовых файлов с TAB разделителем. Они, в свою очередь, готовились бы удобным образом в Excel. К инструменту предъявлялись такие требования:

- все тесты должны собираться в один (zip?) файл
- ... и загружаться в систему, в частности быть частью пакета разработки для переноса на клиентские системы (бинарные объекты W3MI?)
- процедура загрузки должна автоматически определять структуру файлов и проверять ее совместимость с целевой переменной (структурой или таблицей)
- она должна уметь пропускать поля, которых нет в текстовом файле (нестрогий режим) в случае, если полей в целевой структуре слишком много и они не относятся к тесту (как например FI таблицы - зачем готовить "сотню" полей если для теста надо десяток)

Код тест класса в таком случае выглядит так:



Первая часть кода берет TAB delimited файл bseg.txt из каталога TEST1, ZIP архива, загруженного как бинарный объект через SMW0 ...



... и кладет данные во внутренню таблицу с типом строки BSEG (выполняя по ходу всякие ALPHA преобразования и т.п.)

Хранилище данных

Позже появилось еще одно требование: некоторый код достаточно сложно тестировать, если посередине его выполняется select. Конечно, правильный дизайн кода подразумевает разделение выборок из БД и логики, но это не всегда возможно (ну или как минимум довольно сложно). Таким образом нам нужен был простой вызов, который можно было бы использовать вместо select для тестового окружения. Мы назвали эту возможность Store (кстати очень хорошо ложится на ново-анонсированную фичу TEST-SEAM из ABAP 7.50 - когда только она появится в живых системах ...)

Тестовый класс, в таком случае, загружает данные и сохраняет их в Хранилище с определенным ярлыком:



... а боевой код может извлечь данные вместо выборки из БД:



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

Тестовый класс:



Боевой код:



В результате у нас появляется удобная возможность делать полностью динамические тесты, покрывающие большинство кода, в том числе кода с выборками из БД. Конечно, одного данного инструмента для этого недостаточно - требуется правильный дизайн "боевого" кода, разделение бизнес логики и выборок из БД. Но с ZMOCKUP_LOADER и "хранилищем" это происходит гораздо удобнее.



Код проекта доступен на нашей странице на github: http://sbcgua.github.io/mockup_loader/

Надеюсь кому-то окажеться полезным ! =)

С уважением, Александр

Александр, привет.

Давно интересует тема создания mock данных для тестов. Особенно актуально в свете того что предлагает HANA.

Есть ли планы по развитию вашей разработки?

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

Привет Kengur,

Ну, инструмент планирую развивать по ходу появления практических задач, и при "озарениях" на тему как сделать удобнее (так например был придуман store, когда надоело запихивать тестовые данные в атрибуты извне). С HANA честно говоря еще не успел серьезно столкнуться, поэтому что-то сложно прокомментировать.

Оба пункта, таки да, очень небезопасные (для продуктива так точно) и не совсем являются целью инструмента. Но второй пункт (загрузка данных в таблицы) в общем реализуется очень легко - load_data() во внутреннюю таблицу со соответственной структурой и потом сразу insert/modify from table - поидее должно сразу заработать.

А подобныйвариант не рассматривали?

Хорошая статейка, спасибо !

eCatt рассматривали, краткий вывод - неудобно. Судите сами:
- в нашем самом крупном проекте сейчас тестируется 11 классов (и это гдето половина запланированных тестов), всего 114 файликов-мокапов (всмысле не ТЕСТКЕЙСОВ, а ВИДОВ ДАННЫХ, тесткейсов ну допустим по десятку на файл, может чуть меньше). Общий вес тестовых данных в несжатом тексте на текущий момент 200кб (!)
- Для простых вариантов eCatt подходит, но у нас есть тесты, где тестовые данные представляют собой 5-8 таблиц с данными, а результат структра или тоже таблица.
- что делать если есть большая структура, но данные в ней нужны для теста не все (BKPF/BSEG...) - тут может конечно есть решение и в eCatt, не исследовал настолько детально.

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