Смотрю на аbap unit - ну вроде правильная вещь, из лучших побуждений и ради прекрасных целей.
Но вот так в реальной жизни использовать - не могу понять. Индусский форум наполнен примерами тестирования подпрограмм а-ля "сложить два числа" и проверить результат с помощью abap unit.

Засада только в том, что в реальных подпрограммах, ФМах и т.п. обычно используется не по два простых параметра, а с десяток. И часть из параметров - таблицы, иногда с вложенными таблицами, И релевантных для юнит-теста записей - до нескольких десятков.
И получается, что написание юнит-теста (метода класса ...DEFINITION FOR TESTING) - задача посложнее той, что тестируем!
Я может упускаю что-то важное?


Рассмотрим на типичном примере.
Нужно подготовить тестовые данные для формы с входным параметром - таблицей типа PAYRU_RESULT. В таблице записей пара десятков. Из нее нужно выбрать пять, в каждой из которых заполнены все вложенные таблицы с количеством от 2-4 до 2-4 сотен записей.
Выходные параметры, допустим, 10 чисел, значения которых вычислены на основе некоторого запутанного алгоритма, который и нужно протестировать. Причем, алгоритм имеет несколько ветвлений, ну для простоты хотя бы три вариации.

Буду благодарен за практические советы!

Именно так всё и обстоит. Для подавляющей части разработок реализовывать автоматическое/модульное тестирование слишком долго и дорого.

Короче, надо запилить прогу, которая читает БД или принимает на вход заполненную внутреннюю таблицу,
а на выходе выдает текст тестового метода вида



Десяток-другой таких прожек рутиную работу уменьшит процентов на 80

Как я понимаю, самая большая мощь и краса этой тулзы проявляются при использовании несколько иного подхода, чем нам привычен, при разработке - TDD. Ну и никто не отменял принцип: пишите проще - легче тестить. Т.е. клепаются маааленькие методы\фм\т.д. которые легко тестить. Из них как из конструктора клепаются методы побольше, и так далее. Т.е. в идеале - каждый класс хорошо определен и делает только свою работу, а вся разработка разделена на слои.
Кроме того, есть ряд вещей, которым в принципе противопоказаны юнит-тесты: выборки из БД и их анализ, взаимодействие с пользователем и его обработка.
Еще, если речь идет о большой Z-разработке, можно использовать систему юнит-тестов как инструмент регрессионного анализа при изменениях в коде.
Ну и в др. языках используются всякие тулзы для облегчения реализации тестов (mock-объекты), чего в абап - не положили

Согласен. TDD можно и нужно применять без оглядки на начальнегов и всякие штуки типа abap unit. Даже банальное выписывание кейсов на бумажку положительно влияет на работу. Прочувствовал на практике.

TDD в нашей отрасли - зло, в половине задач, пока пишешь тесты поменяется постановка.

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

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

И опять же постановки меняются так часто и срочно, что нередко тестирование производится сразу на продуктивных данных.
Может быть я не умею готовить TDD?

Лично я использовал юнит-тесты, когда надо было разработать свою систему классов для проверок. Т.е. на входе данные, есть масса настроек, по определенным условиям считываются настройки проверок, выбираются нужные методы проверок, выполняются проверки. И тоже самое для замещений на другом проекте (это сейчас в системе есть BRF+, и я про нее знаю, тогда пришлось склепать свой велосипед). Все очень хорошо (за исключением чтения данных, как я писал выше) накрывается тестами. При смене настроек, модификации проверок - ррррраз и протестилось все.

SAP утверждает, что для этого нужно использовать ECATT.
Вот только мне таких заказчиков встречать не приходилось. А использовать эту штуку по личной инициативе абапера - невозможно, imho. Слишком навороченно и в тестовых данных должна быть дисциплина и порядок.

...все течет, все меняется.. вот уже и mock-объекты появились

Во, это как раз подходящая штука для тестирования.

Я не очень догоняю как использовать ECATT для тестирования. Вот пример: мне нужно через web загрузить файлик, создать на его основе документы, изменить их и проверить результат. И как?

в версии 7,4 09

Хороший вопрос! Пару лет назад я тут задавала похожий вопрос по поводу применения ООП в ABAP - вроде как в теории все замечательно, но насколько это применимо на практике?

Меня всегда интересует, чем именно занимаются в SAP люди, которые агитируют за ту или иную технологию. 99% моей работы составляют очень простые по сути вещи для которых какие-то дополнительные усилия для unit test были бы просто нецелесообразны. В таких случаях - это решение для проблемы, которой нет.

А в более сложных программах очень часто, как отмечено выше, проблема другая - меняющиеся задачи. Например, был у нас небольшой проект, для которого хорошо было бы применить и ООП, и unit test, и UML, но он развивался как перекати-поле и маленькая программка разрослась в процессе до неузнаваемости. Оглядываясь назад, я не знаю как можно было ее реализовать лучше, не зная заранее окончательных условий.

Кстати, Paul Hardy (автор новой книги про ABAP) как раз недавно написал блог об этом на SCN: http://scn.sap.com/community/abap/blog/ ... der-my-bed

Реализация решения, которого нет в SAP. Локализации SAP и роллауты больших проектов (допиливание напильником)



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



Ну во-первых, вот этот ваш абзац можно так же использовать как подтверждение моей мысли выше.
А во-вторых: как раз для работы в изменяющихся условиях и нужны все эти ООП, инит-тесты и УМЛ. Попустительствуя легкому подходу в начале, на выходе - получаем "как всегда".
И - да: умение отличить случай, когда надо делать просто, а когда надо делать по модным методологиям с новыми инструментами-технологиями - и есть признак опытного специалиста, имхо.

ЗЫ: моя любимая статья на эту тему на хабре