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

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

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

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

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

 

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

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

Сколько?

Тестовых классов должно быть ровно столько сколько нужно. Как минимум, каждый большой объект (группа функций, программа, класс) должен иметь один тестовый класс, можно больше.

Если у вас простая группа из двух-трёх связанных функций, то к ней достаточно и одного класса.

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

Главным критерием делимости является метод SETUP. Такой метод в классе должен быть один, вызывается он автоматически перед каждым тестовым методом. Отсюда вывод: классы необходимо образовывать по принципам наличия общей инициализации или её отсутствию.

Кто?

Как называть класс? Ну неплохо было бы, если он будет начинаться с префикса “lcl”, иметь в названии упоминание основного объекта и какое-то слово, имеющее отношение к тестированию.

Если группа функций называется ZFOO, то пусть тестовый класс называется lcl_zfoo_test. Идём дальше, не заморачиваемся.

Где?

Тесты могут находиться в любом месте исходного кода, но разумно отделять работающую функциональность от тестов.

Так мастер для групп функций создаёт отдельную include-программу по предопределённому шаблону: например: LZFI_BTET99 для группы функций ZFI_BTE. Ничего плохого в этом не вижу, надо принимать за образец и продолжать в том же духе.

Также и в программах типа REPORT: пишите тесты строго в одной отдельной include-программе.

Какие?

Какие методы должен содержать класс?

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

Можно меньше, можно больше, если тесты от этого станут лучше.

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

Их может быть меньше, так как некоторые функции выполняют отображение данных. Это уже будет несколько портить статистику покрытия.

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

Когда?

Нельзя каждые пять минут запускать полный цикл модульных тестов. Поэтому можно придерживаться следующих рекомендаций:

• Разработчик прямые тесты может запускать по необходимости вручную
• Прямые модульные тесты должны быть выполнены при деблокировании запросов на изменение, тест смежных и  зависимых объектов разработки – рекомендуется
• Полные тесты следует запускать при достижении контрольных точек

 

Зачем?

В череде вопросов не забывайте главное: тесты – это не самоцель. Всё должно нести пользу.

Прямая реальная польза от тестов будет только в те моменты, когда по прошествии времени тесты будут провалены, когда кто-то будет допиливать эту функциональность.

А прямо сейчас можно извлечь только косвенную пользу:

• Тесты документируют сценарии использования
• Тесты помогают выявить места, требующие внимания (рефакторинг)
• Тесты помогают выполнить базовые проверки тех мест, которые сложно тестировать вручную