Куда пристроить модульные тесты в ABAP. Часть шестая. Промежуточные итоги.

Хочу с экзитами закончить и подвести промежуточные итоги в этой части:

  • Код теста получается больше продуктивного кода.
  • Во многих случаях подходы TDD оправданы и рекомендуются к употреблению.
  • Обзор существующего продуктивного кода без тестов вызывает существенное напряжение мозговых извилин.
  • Если пытаться покрыть тестами уже написанный код, то часто без рефакторинга не обойтись. А рефакторинг – несколько другая и более сложная задача, чем само покрытие тестами. Рефакторинг можно отложить до момента, когда вы будете делать с кодом что-то ещё.
  • Если у вас есть продуктивный код, который не меняется годами, то его покрывать тестами нужно в последнюю очередь.
  • Код может быть остаться непокрытым из-за замкнутой петли: Нельзя сделать правильные тесты, потому что сначала надо сделать серьёзный рефакторинг, а делать рефакторинг не рекомендуется пока нет тестов. Разрывайте эти петли, если тесты всё-таки нужны.
  • В некоторых случаях выполнить покрытие тестами не получается. Так бывает. Смиритесь.
  • По некоторым метрикам подсчета полноты покрытия гораздо проще добиться 100%, чем по другим. Но это не значит, что нужно делать так, как проще.
  • Тесты нужны не для того, чтобы добиться 100%, а для того, чтобы они когда-нибудь правильно упали. Потому что уметь правильно падать – это самое главное. Если это верно для каратистов и велосипедистов, значит и для программистов тоже. Лучше правильно упасть плохо крутя педали, чем неправильно упасть хорошо крутя педали.

Куда пристроить модульные тесты в ABAP. Часть пятая. Тридцать восемь попугаев

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

Процент покрытия – цифра сомнительная, ровно настолько же сомнительная, как и “средняя температура по больнице”. Процент покрытия по проекту – это среднее покрытие его частей. То есть: Модуль-1 имеет покрытие 90%, Модуль-2 имеет покрытие 10%, в среднем покрытие будет равно 50%, если допустить что модули примерно равны по содержимому.

А что значит равны? И что такое 10%?

(далее…)

Куда пристроить модульные тесты в ABAP. Часть четвёртая. Как вы лодку назовёте…

Продолжаю записывать мысли на тему.

Для работы ABAP Unit неважно:

  • сколько у вас тестовых классов вообще;
  • как называется тестовый класс;
  • в каком месте он расположен;
  • как называются его методы.

Главное, чтоб локальный класс:

  • был доступен;
  • имел кличку “for testing”;
  • имел методы с кличками “for testing”.

 

Но, с другой стороны, даже имена переменных-то тоже не являются случайным набором букв.

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

(далее…)

Про дилетантов

Не так давно на Хабре пробежала статья, в которой некий дилетант кидал камни в огород SAP.

Один из камней:

Почему люди переводившие продукт не понимали русский язык? Потому что даже при перепечатывании русскоговорящий человек должен был усомниться, увидев фразу «Пушномолочная свинья-несушка» — так до определенного времени называлась программа RAIMEWMS (сейчас название уже исправили). В оригинале она называется «Eierlegende Wollmilchsau», что переводится как «Мастер на все руки», но умный Magic Gooddy посчитал, что Wollmilchsau – это 3 отдельных слова (Woll, milch, sau) и перевел фразу «Eierlegende Woll milch sau» как «Яйцо укладки шерсти молока свиноматки». Остается только гадать, как это потом превратилось в «Пушномолочная свинья-несушка».

Вот вопрос: кто больший дилетант? Тот, кто сделал такой перевод, или тот, кто кинул камень?

По пунктам:

(далее…)

Куда пристроить модульные тесты в ABAP. Часть вторая. Первые грабли.

Первый шаг сделан. Теперь нужно расширить и углубить наше наступление. Глобальная цель – максимально полное покрытие тестами, в рамках целесообразности происходящего.

Грабля первая. Обработка ошибок.

Допустим, наш ФМ делает не замещение значений, а проверку:

function zfi_bte_00001120.

  if ls_bseg-zuonr eq space.
    message ‘Поле Присвоение обязательно для заполнения’ type ‘E’.
  endif.

endfunction.

Тут есть две проблемы.

(далее…)

Куда пристроить модульные тесты в ABAP. Часть первая. Первый тест.

В умных книгах и статьях много про это написано в целом. Но вопрос по части специфики в ABAP-программировании раскрыт мало.

ABAP-программирование может быть совсем разным. Но почти в любом большом проекте его можно разложить на следующие кучи:

  • Экзиты (user-exits). Сюда относятся: проверки, замещения, BTE, BAdI, CMOD и подобные способы расширения стандартной функциональности.
  • Собственное приложение. Вполне вероятно, что это будет вариация на тему CRUD.
  • Отчеты. Можно сказать, что отчёт – это такое собственное приложение, но у программ такого рода есть свои нюансы.
  • Входящая интеграция, исходящая интеграция. Мы вызываем, нас вызывают, как это часто не совпадает.
  • Вспомогательные библиотеки. Полуфабрикаты, необходимые для построения готового продукта.

А теперь отдельно про экзиты.

(далее…)

Формирование фоновых заданий и массовый запуск транзакции ASKB/ASKBN

Изначальная постановка задачи сводилась к тому, что в системе необходим еженедельный автоматический запуск транзакции ASKB. Ничего сложного.

Загвоздка первая: транзакция ASKB полно и продуктивно работает только в фоновом режиме. На всякий пожарный случай от греха подальше.

Загвоздка вторая: транзакция ASKB не умеет работать с несколькими БЕ. Экран выбора не оставляет выбора. Если бы на нашем проекте было бы мало БЕ (одна-две-три), то можно было бы просто создать напрямую несколько фоновых заданий и дело в шляпе. Но если у нас сотня БЕ, то уже необходима собственная запускалка, раз стандартной нет никакой.

Отлично, приступаем к реализации.

(далее…)

Ещё один потолок

Работа в отчётах с параметром SELECT-OPTIONS проста.

Сначала определяем:

select-options: s_anln1 for anla-anln1.

Потом используем:

select * from anla into table gt_report where anln1 in s_anln1.

Всё просто на первый взгляд. При таком коде внутри Open SQL происходит простая работа: OpenSQL трансформируется в NativeSQL, а там подобной конструкции нет. Поэтому фактический запрос превращается приблизительно в следующее:

select * from dbchema.anla where anln1 = ‘1’ or anln1 = ‘2’ or anln1 = ‘3’;

И если бы забьём очень много значений в поле выбора, то длина получающегося в результате SQL запроса будет расти линейно. Именно где-то тут я встретился с узким местом, в котором меня стукнули по носу динамической ошибкой DBIF_RSQL_INVALID_RSQL. Интересно, а почему не SAPSQL_STMNT_TOO_LARGE?

В моём случае это примерно 9980 значений типа ANLN1. Это эмпирическое число видимо будет разниться от системе к системе, от используемого типа данных и прочих условий. И как его гарантированно предсказать в общем случае?

Есть в недавней игре Saints Row: Gat Out of Hell одно достижение: десять раз стукнуться головой о потолок.

 

Achievement unlocked

 

Как быть?

В моём случае я решил, что пользователю не следует выдумывать себе сценарии, в которых необходимо вводить десять тысяч значений в поле выбора. Ибо нефиг. Для красоты можно разве что поставить проверку на экране выбора, чтобы в эти очень редкие моменты красиво выругаться. Динамическая ошибка – это не красиво.