И не говорите мне, что я зануда.
Дело было так. Я когда-то уже вещал вам про TDD методологию, а сегодня решил на практике попробовать как оно работает в SAP. Сделал простой OData сервис, его и решил протестировать автоматизированно.
А теперь я хочу его автоматизированно тестировать. Ранее я рассказывал про sECATT. Сегодня поговорим про Unit тестирование. Это такая штука, которая программируется на языке программирования ABAP и позволяет проверять логику работы _внутри_ программы. То есть, она не имитирует работу пользователя, а проверяет внутренние процедуры, методы, функции на ожидаемый результат. Например, всегда должно сохранять данные с корректным форматом, никогда нельзя сохранять данные с некорректным форматом. Делаем для этого два метода — тест на положительный результат и тест на отрицательный результат.
Так, вернемся к нашим баранам. Есть класс Data Provider Class (DPC), который для OData модели поставляет данные по CRUD. То есть мы его мучаем HTTP запросом типа GET, например, а он нам данные отдает после аутентификации и авторизации. Нам нужно написать тест, который проверит, что данные на самом деле отдаются и соответствуют эталонным.
Для этого нам нужно сделать локальный класс, который будет тестировать методы DPC. Исходники ниже. Программист быстро разберется.
Все дело в плюшках!
Вот смотрите. Кроме того, что программулька умеет запускать эти тесты, собирать по ним статистику, делать это в фоне, тем самым автоматизируя контроль качества, уживается с код инспектором; программулька умеет думать! Ну как думать, она смотрит какие строчки исходного кода были протестированы или, говоря иначе, покрыты тестами.
То есть, прелесть ситуации в том, что система покажет, какие бизнес-ситуации вы еще не описали в тестах. Такая подсказка напомнит нам о нужной ситуации, мы ее напишем в виде теста.
Завтра прилетает из смежной области новая заявка. Кто-то что-то правит, все ломается. Вот чтобы это сломанное хозяйство не перенести в продуктив и нужны тесты. Тест уже в разработке проверит, что тот или иной алгоритм в куске кода не работает так, как было заложено в эталонном тесте. И тогда нужно либо искать ошибку в нововведениях, либо изменять тест под новые требования.
class zcl_Ut_Z_Hrbot definition for testing
duration short
risk level harmless
.
*?
*?
*?
*?zcl_Ut_Z_Hrbot
*?
*?f_Cut
*?
*?ZCL_Z_HRBOT_01_DPC_EXT
*?
*?
*?X
*?
*?
*?
*?X
*?
*?
*?
*?
private section.
data: mo_request_context_object type ref to /iwbep/cl_mgw_request_unittst.
data: ms_request_context_struct type /iwbep/cl_mgw_request_unittst=>ty_s_mgw_request_context_unit.
data: mo_data_provider type ref to zcl_Z_Hrbot_01_Dpc_Ext.
methods: setup.
methods: teardown.
methods: lt_get_Entityset for testing.
endclass. "zcl_Ut_Z_Hrbot
class zcl_Ut_Z_Hrbot implementation.
method setup.
create object mo_data_provider .
endmethod.
method teardown.
endmethod.
method lt_get_Entityset.
DATA: lr_data TYPE REF TO data.
DATA: ls_response_context TYPE /iwbep/if_mgw_appl_types=>ty_s_mgw_response_context.
DATA: ls_data TYPE zmes_quota.
FIELD-SYMBOLS: TYPE ANY TABLE.
ms_request_context_struct-technical_request-source_entity_type = 'Quota'.
ms_request_context_struct-technical_request-target_entity_type = 'Quota'.
ms_request_context_struct-technical_request-source_entity_set = 'QuotaSet'.
ms_request_context_struct-technical_request-target_entity_set = 'QuotaSet'.
mo_request_context_object = mo_data_provider->/iwbep/if_mgw_conv_srv_runtime~init_dp_for_unit_test(
is_request_context = ms_request_context_struct ).
try .
mo_data_provider->/IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_ENTITYSET(
exporting
io_tech_request_context = mo_request_context_object
importing
er_entityset = lr_data
es_response_context = ls_response_context
).
catch /iwbep/cx_mgw_busi_exception.
catch /iwbep/cx_mgw_tech_exception.
endtry.
assign lr_data->* to .
loop at into ls_data.
exit.
ENDLOOP.
cl_Abap_Unit_Assert=>assert_Equals(
act = ls_data-pernr
exp = 1
msg = 'Testing one employee'
* level =
).
endmethod.
endclass.
One Comment
Vitaly Potseluev
Проверка связи 😉