Эта статья ориентирована на ABAP-разработчиков в системах SAP ERP. Она содержит много специфических для платформы моментов, которые малоинтересны или даже спорны для разработчиков, использующих другие платформы.
В умных книгах и статьях много про это написано в целом. Но вопрос по части специфики в ABAP-программировании раскрыт мало.
ABAP-программирование может быть совсем разным. Но почти в любом большом проекте его можно разложить на следующие кучи:
- Экзиты (user-exits). Сюда относятся: проверки, замещения, BTE, BAdI, CMOD и подобные способы расширения стандартной функциональности.
- Собственное приложение. Вполне вероятно, что это будет вариация на тему CRUD.
- Отчеты. Можно сказать, что отчёт – это такое собственное приложение, но у программ такого рода есть свои нюансы.
- Входящая интеграция, исходящая интеграция. Мы вызываем, нас вызывают, как это часто не совпадает.
- Вспомогательные библиотеки. Полуфабрикаты, необходимые для построения готового продукта.
И сейчас отдельно про экзиты.
Часть первая. Первый тест
Экзит – это отдельный метод класса или функциональный модуль строго определенного интерфейса с вашим ABAP-кодом, который вызывается в определённых бизнес-операциях (транзакциях) в некоторый определённый момент. Вроде плагина.
Классический случай: функциональный модуль замещения без глобальных данных. И пусть примером нам будет событие BTE 1120 (замещение при проводке бухгалтерского документа).
В случае экзитов, обычно тест заключается в выполнении пользовательской операции, которая связана с этим событием. Мы могли бы симулировать эту пользовательскую операцию, сохранить документ, и потом проверить этот документ на требуемые свойства. Но в том-то то и заключается одно из важных отличий модульного тестирования от обычного тестирования, что здесь так действовать не нужно.
У нас есть функциональный модуль с несколькими входными параметрами и несколькими выходными параметрами. Мы что-то подаём на вход, и на выходе получаем какое-то изменение.
Значит наш модульный тест должен быть таким:
- готовим набор входных параметров, который симулирует нужный нам эталонный документ
- запускаем наш функциональный модуль
- проверяем, что выходные параметры содержат требуемые значения
Допустим, изначальная постановка была следующей:
Если проводится бухгалтерский документ вида VB и в позициях идёт проводка по дебету счёта 1080, то весь документ должен провестись с признаком “Красное сторно”.
Можно применить и TDD, но мы (пока) такую методологию не будем брать на вооружение.
В итоге мы написали в ФМ ZFI_BTE_00001120 некоторый код:
Код готов, мы хотим теперь написать тест для него.
Варианта два:
- запускаем мастер
- делаем всё ручками
Я считаю мастер сделан почти с человеческим лицом, годный.
Сначала посмотрим на мастер, для этого заходим в группу функций и дальше по меню “Создать – Другие объекты – Сгенерировать тестовый класс” и идём по шагам.
Класс создаётся не для конкретного ФМ, а для группы функций целиком:
Можно придумать имя для класса и поставить какие-то галочки:
Выбираем, какие именно функциональные модули нам нужны:
Далее, далее, далее… Смотрим, что нам мастер нагенерировал:
Методы SETUP и TEARDOWN пустые. Движок будет запускать их соответственно в начале и в конце каждого теста.
К каждому выбранному функциональному модулю был сгенерирован тестовый метод строго по имени нашего ФМ.
И реализация базовой проверки в виде простого вызова уже есть:
Как видите, ничего сверхъестественного мастер не сделал, значит мы можем и сами такие заготовки делать.
Если теперь накидать вокруг этого кода тест именно для нашего бизнес-сценария, то мы подойдём к промежуточному итогу:
Я полагаю, что не обязательно полностью симулировать документ, если это не влияет на работу всего комплекса тестов: достаточно предоставить только самое необходимое для работы бизнес-сценария. Поэтому можно опустить даты, суммы, наличие кредитора, вид счёта и тому подобные параметры.
Получился годный рабочий сценарий, планирую использовать в боевой обстановке.
Можно накидать тесты и для других функциональных модулей в группе функций.
Теперь мы можем запускать модульные тесты по меню “Функциональный модуль – Выполнить – Тесты модулей”:
Тихое, маленькое, зелёненькое, всё хорошо. А если бы мы ошиблись или в тесте, или в самом ФМ, то картина была бы такая:
Всё сломалось! Что и требовалось доказать.
BTW: Вот наконец-то, есть применение табличным функциям! В моём текущем активном проекте большой апгрейд всё-таки произошёл, и теперь вместо старинных APPEND и READ можно писать такие вкусные штуки.
BTW: Там же рядом есть подпункт “С измерением покрытия”, но до него мы ещё доберёмся.
BTW: Да, есть огрехи в русской версии, не будем их осуждать.
На сегодня пока хватит… и если меня выпустят из песочницы, то продолжу.
PS. На Хабре нет подсветки для ABAP-кода.
Автор: ivanbolhovitinov
