С новыми инструментами ABAP-программирования легче тестировать программу, отлаживать ее и анализировать причины ошибок. Мы рассмотрим каждое из этих действий и обсудим, как они выполняются в ABAP in Eclipse.

Paul Hardy

ABAP® to the Future


**Оригинал (англ.): ABAP to the Future. Пол Харди. Издательство SAP PRESS. Раздел 1.3. 2019, с. 63–71.

Через всю книгу красной нитью проходит одна мысль: с новыми инструментами ABAP-программирования легче тестировать программу, отлаживать ее и анализировать причины ошибок. В следующем разделе мы по порядку рассмотрим каждое из этих действий и обсудим, как они выполняются в ABAP in Eclipse.

1.1.1 Функциональное тестирование и покрытие кода

В Главе 3 я подробнее расскажу о функциональном тестировании в ABAP и философии разработки через тестирование. Не буду забегать вперед и приводить доводы, почему функциональное тестирование — это хорошо (действительно, лучше ничего и быть не может). Вместо этого поговорим о том, как ABAP in Eclipse справляется с двумя основными проблемами при написании функциональных тестов.

Проблема 1. Трудоемкое создание методов тестирования

В SE80 предусмотрен мастер создания методов тестирования на основе существующих методов. Это подход от противного, а мы хотим создать в первую очередь методы тестирования.

В Eclipse для этого нужно создать новый глобальный класс. В нижней части экрана находится ряд вкладок, одна из которых называется Test Class (Класс теста). Обратите внимание: в реальном классе еще ничего не создано. Перейдите на вкладку Test Class (Класс теста), введите слово «test» и нажмите комбинацию клавиш (CTRL) + (SPACE).

Откроется диалоговое окно с вопросом, что вы хотите создать: запрос на перенос или класс теста. Верный ответ — класс теста. Если вы выбрали его, то увидите содержимое Листинг 1.13.

*"* использовать этот исходный файл для создания классов функциональных тестов ABAP
CLASS ltcl_definition FINAL FOR TESTING
  DURATION SHORT
  RISK LEVEL HARMLESS.

  PRIVATE SECTION.
    METHODS:
      first_test FOR TESTING RAISING cx_static_check.
ENDCLASS.

CLASS ltcl_ IMPLEMENTATION.
  METHOD first_test.
  cl_abap_unit_assert=>fail( 'Реализуйте свой первый тест здесь' ).
  ENDMETHOD.
ENDCLASS.

Листинг 1.13 Исходный файл для класса функционального теста ABAP

Создание схематичного класса теста не высший пилотаж функционального тестирования, но он подходит для разработки через тестирование намного лучше, чем стандартные процессы SE80. Разумеется, нужно изменить сгенерированный код и указать имя класса теста и метод тестирования и при необходимости добавить другие методы тестирования. Суть в том, что вы сначала создаете методы тестирования, а затем копируете определение в реальный класс.

Из Раздела 1.2.3 мы помним, что, имея определение, можно создать схему реализации, используя сочетание клавиш (CTRL) + (1). При автоматической генерации определение должно добавляться автоматически, например, DATA: mo_cut TYPE REF TO ycl_monster_unit_tests. (У меня ничего не вышло, как я ни старался, поэтому добавил определение вручную. В документации говорится о том, что добавление происходит автоматически. Возможно, в новых версиях этот недостаток исправят).

В переименованном функциональном тесте first monster сначала определите результат теста, а затем добавьте строку mo_cut->first_monster( )., которая будет методом в еще не существующем главном классе. Если нажать клавиши (CTRL) + (1), появится запрос на создание метода в реальном классе, который нужно подтвердить. Помните, что тест был создан раньше реального метода — в этом и заключается суть разработки через тестирование.

В целом разработка через тестирование происходит быстрее и проще (и в правильном порядке) с помощью ABAP in Eclipse, чем с помощью аналогичных процедур в стандартной среде ABAP Workbench.

Проблема 2. Нельзя определить охват программы тестированием

Функциональное тестирование направлено на максимальную (в пределах человеческих возможностей) уверенность в том, что при изменении какой-либо части программы — будь то исправление ошибки или добавление новых функций — другие части программы остаются неповрежденными. В реальной жизни разработчики обычно убеждаются, что изменение в одной области всегда влияет на что-то в другой области. Этот тревожный знак говорит о том, что, вероятно, не стоит писать такие уязвимые программы.

Функциональное тестирование позволяет выполнять автоматическое регрессивное тестирование, и можно быть уверенным, что изменение даже одной строки кода не повлечет за собой губительных последствий для какой-либо другой части программы. Разумеется, для полного спокойствия нужно, чтобы каждая строка кода в каждой подпрограмме и каждом методе проходила такое регрессивное тестирование. Создание таких тестов — нелегкая работа, к которой готовы лишь немногие. Подробнее этот вопрос мы обсудим в Главе 3. Тем не менее, если вы уверовали и готовы к созданию таких тестов, следующий шаг — понять, какая часть кода будет действительно протестирована. Если прогноз составляет менее 100 %, нужно найти решение.

В Java есть инструмент под названием Clover, который измеряет процент кода, покрытый функциональным тестированием. Когда я узнал о нем, то подумал, что здорово было бы использовать его в ABAP, и что, возможно, я должен внести свою лепту в разработку такого инструмента. Оказывается, в ABAP in Eclipse подобная функция уже существует (и, по правде сказать, в SE80 тоже, в последних версиях SAP NetWeaver).

В последнем разделе мы создали один метод тестирования. Теперь вы создадите реальный метод, к которому будет применен тест. А потом еще один реальный метод, для которого теста еще не существует, — в том случае если вы упретесь и решите доказать себе, что создание методов без тестирования экономит время. (Это! Не! Так!)

Говорят, что малым довольствуются лишь глупцы, но лично мне доставляет огромное удовольствие возможность написать определение метода без тестирования, приложив минимум усилий: нажать сочетание клавиш (CTRL) + (1) и увидеть, как генерируется реализация и как курсор перепрыгивает в реализацию. Еще говорят, что каждая секунда должна быть на счету, и так как эти инструменты помогают сэкономить несколько секунд то там, то тут в течение рабочего дня, то в итоге вы выигрываете во времени.

CLASS ycl_monster_unit_tests IMPLEMENTATION.

  METHOD first_monster.
    WRITE:/ 'I am the First Monster'.
  ENDMETHOD.

  METHOD second_monster.
    WRITE:/ 'I am the Second Monster'.
  ENDMETHOD.

ENDCLASS. "Реализация функционального тестирования монстра

Листинг 1.14 Метод без тестирования

В SE80 вам нужно было бы выбрать путь меню Program • Test • Unit Test (Программа •Тестирование • Функциональное тестирование). В ABAP in Eclipse нужно лишь нажать сочетание клавиш (CTRL) + (SHIFT) + (F10). Произойдет чудо: вы увидите все ошибки, которые могли возникнуть в результате изменений кода. Нажав сочетание клавиш (CTRL) + (SHIFT) + (F11), вы перейдете на следующий уровень. (F11 лучше F10 по той же причине, по которой шестизвездочный отель лучше пятизвездочного — больше преимуществ.)

Вы видите два результата (Рис. 1.20). Во-первых, весь протестированный код будет выделен. Еще важнее то, что откроется обзорный ракурс, в котором отобразится процент охвата каждого метода автоматическими функциональными тестами.

Рис. 1.20 Покрытие кода функциональным тестированием

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

1.1.2 Отладка

Отладчик — один из лучших инструментов ABAP Workbench. В Главе 5 я кратко расскажу о новых функциях отладчика, о которых вы можете еще не знать. Напомню, что говорим мы об ABAP in Eclipse, и вы можете задаться вопросом: зачем говорить об отладке в среде, которая предназначена исключительно для разработки? Вернемся к функциональному тестированию: при наличии ошибки нужно отладить программу и найти причину.

У меня для вас есть плохая и хорошая (и на первый взгляд неправдоподобная) новость. Плохая новость: на момент работы над книгой отладчик в ABAP in Eclipse уступает в функциональности отладчику в системах SAP, хотя с течением времени этот недостаток, конечно, будет исправлен. А теперь, внимание, хорошая новость! Узнав ее, впрочем, вы можете подумать: «Он бредит или под наркотиками». Хорошая новость: исходный код можно изменять в процессе отладки.

В следующем примере мы добавим в код явную ошибку, а затем отладим код и посмотрим, что пошло не так. В Англии о людях, которые хорошо в чем-то разбираются, говорят: «Он знает, сколько штук в пяти бобах». Мы тоже знаем — их пять. Допустим, вы хотели добавлять новых монстров, пока их не станет пять, но пропустили одного и в итоге получили только четырех — очевидная ошибка (Листинг 1.15).

CLASS lcl_how_many_monsters DEFINITION.
  PUBLIC SECTION.
  METHODS how_many_make_five RETURNING VALUE(rd_how_many) TYPE i.
ENDCLASS. "Определение количества монстров

CLASS lcl_how_many_monsters IMPLEMENTATION.
  METHOD how_many_make_five.
    DO 100 TIMES.
      ADD 1 TO rd_how_many.
      IF rd_how_many = 4.
        RETURN.
      ENDIF.
    ENDDO.
  ENDMETHOD.
ENDCLASS. "Реализация количества монстров

DATA: ld_how_many TYPE i,
      lo_counter  TYPE REF TO lcl_how_many_monsters.

START-OF-SELECTION.
  CREATE OBJECT lo_counter.
  ld_how_many = lo_counter->how_many_make_five( ).
  WRITE:/ ld_how_many.

Листинг 1.15 Только четыре монстра

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

Между тем, в ABAP in Eclipse можно изменить исходный код в процессе отладки. То есть, можно добавить недостающую строку для создания последнего монстра прямо в отладчике и затем перейти на новую строку и посмотреть, все ли работает правильно. Это просто революция в мире отладки. Увидев такое впервые, вы можете подумать, что кто-то подсыпал вам в чай ЛСД. Невероятно, но факт. Когда SAP подтянет остальные функции отладчика в ABAPin Eclipse до уровня стандартного отладчика, мы все только выиграем.

Как и в стандартном редакторе кода ABAP, можно определять, в какой момент программа перейдет в режим отладки во время выполнения. Можно добавить программные точки останова с помощью меню или сочетания клавиш (CTRL) + (SHIFT) + (B). Можно добавить аппаратные точки останова, например BREAK BLOGGSJ. Во время прогона программы (меню Run • Run as ABAP Application[Прогон • Прогнать как приложение ABAP]) или функционального тестирования, как только будет достигнута точка останова, появится окно с вопросом: хотите ли вы перейти в режим отладки? Ответ на этот глупейший из всех глупых вопросов очевиден: вы хотите. Поэтому нужно выбрать ответ «Да» и поставить галочку, что его нужно запомнить и больше не отвлекать вас по пустякам.

Откроется окно отладчика. Оно выглядит несколько непривычно (Рис. 1.21). Изменять значения переменных во время выполнения совсем просто. Для этого нужно дважды щелкнуть в поле с текущим значением.

Внимание. Хьюстон, у нас проблема

Если вы используете недостаточно новую версию бэкэнд-системы SAP, то есть, с версией ядра ниже 721, отобразится сообщение об ошибке вида: «Отладка в ABAP in Eclipse не поддерживается в системе XYZ. Выполните отладку в SAP GUI».

Рис. 1.21 Отладка в Eclipse

Вы видите ошибку: в коде указано значение 4, а не 5. Измените оператор на IF RD_HOW_MANY = 5. На текущее выполнение это никак не повлияет (а то можно было бы заподозрить черную магию), но после окончания отладки и повторного прогона программы все встанет на свои места.

Оформите подписку sappro и получите полный доступ к материалам SAPPRO

У вас уже есть подписка?

Войти