Границы бизнес-логики, внедрение зависимостей, тестовые двойники и TEST-SEAM. Ограничения по версиям указаны отдельно; запуск тестов в SAP не заявляется.
4 мин чтения·База знаний
Ревизия 1Общие понятияЧастичное покрытиеКонтекст: CTX-GENERALдокументальная опора: недостаточно данных
Справочный материал. Контракты данных, архитектурные решения и ограничения применения. Источники приведены в материалах, где используются внешние основания.
Тестируемость финансовой логики зависит от того, можно ли отделить вычисление от чтения базы, системного времени, вызовов функций, пользовательского ввода и внешних сервисов. Здесь описан способ выбрать тестовую границу. Это справочное руководство по архитектуре ABAP, а не свидетельство компиляции или запуска примеров в SAP.
Опишите поведение через входы, выходы и ошибки. Например, распределение суммы между получателями должно сохранять общий итог, а равные остатки разрешаются стабильным правилом. Такой контракт можно проверять отдельно от поиска данных, выбора периода и сохранения документа.
Полезная граница отделяет вычисление от окружения:
Часть
Ответственность
Как проверять
Расчёт
Правила распределения, округления и сверки
Фиксированные входы, границы и инварианты
Порт данных
Получить исходные позиции и параметры
Двойник возвращает подготовленный набор строк
Порт времени или курса
Определить дату, курс или календарь
Явно заданные значения сценария
Адаптер платформы
Вызвать таблицы, API или функции SAP
Интеграционная проверка в подходящей системе
Не каждому классу нужен интерфейс. Выделяйте зависимость, если она меняется отдельно, создаёт побочный эффект или мешает детерминированному тесту. Лишние уровни абстракции усложняют код и сопровождение.
При внедрении зависимости объект получает collaborator через конструктор или параметр вместо того, чтобы создавать его внутри бизнес-метода. В тесте production-компонент заменяется заглушкой, fake или mock-объектом. Заглушка возвращает фиксированный ответ; mock может также проверять ожидаемое взаимодействие. Двойник описывает конкретный тестовый сценарий, а не внутреннее устройство настоящей системы.
ABAP OO Test Double Framework позволяет настраивать поведение вызовов и проверять взаимодействия. Документация SAP указывает поддержку глобальных интерфейсов и глобальных классов на подходящих версиях backend. Также перечислены ограничения для локальных типов и некоторых видов классов, конструкторов и методов. Перед выбором этого средства проверьте версию и ограничения целевой системы.
Небольшой финансовый пример: сервис распределения получает допустимых получателей через интерфейс-поставщик данных. Тест передаёт двойнику две позиции и сумму 101, запускает расчёт, проверяет суммы получателей, сохранение итога и отсутствие вызова сохранения. Отдельная интеграционная проверка изучает адаптер чтения и запись в целевой среде.
TEST-SEAM ... END-TEST-SEAM обозначает участок, код которого можно заменить через TEST-INJECTION во время теста. Это помогает постепенно тестировать существующий код, который пока нельзя безопасно переработать. SAP документирует ограничения: injection должна находиться в подходящей области компиляции; например, seam и injection ограничены одним function pool, а reports этот механизм не поддерживают.
Seam может быть временным переходным швом. Если зависимость стала частью контракта класса, явный интерфейс обычно легче найти и сопровождать. Не оборачивайте большой метод в seam только ради покрытия: так можно скрыть реальное поведение вместо его проверки.
SAP описывает отдельную инфраструктуру test double для function modules и указывает её доступность начиная с SAP NetWeaver AS ABAP 7.56. В более ранней системе может потребоваться интерфейс, seam или другой совместимый механизм. Не предполагайте, что средство доступно во всех версиях.
Зафиксировать уровень детализации операции и входной контракт: валюту, период, ключи, точность и поведение при пропуске данных.
Проверить расчёт на обычном, нулевом и отрицательном значениях, а также при конфликтующих ключах.
Изолировать время, курсы, чтение данных и вызовы платформы там, где они влияют на результат или создают побочный эффект.
Проверить, что двойник использует публичный контракт и не зависит от приватных деталей реализации.
Запустить ABAP Unit и нужные интеграционные проверки в целевой системе и сохранить фактический отчёт.
Пункты 1-4 являются рекомендацией к проектированию. Пятый пункт здесь не выполнен: у проекта нет подключённой ABAP-системы, поэтому страница не заявляет о компиляции, ABAP Unit, ATC или runtime-проверке.
SAP Help описывает отдельные механизмы ABAP Unit и версии их доступности. Это не подтверждает, что пример выше реализован в SAP, подходит любой версии или прошёл запуск. Ссылки сохранены как метаданные; локальные текстовые снимки источников не получены.
Financial logic is easier to test when calculation is separated from database reads, system time, function calls, user input, and external services. This guide describes how to choose a test boundary. It is an ABAP architecture reference, not evidence that examples were compiled or run in SAP.
Describe behavior using inputs, outputs, and errors. For example, allocating an amount among recipients must preserve the total, with stable handling of equal remainders. That contract can be tested separately from data lookup, period selection, and document persistence.
A useful boundary separates calculation from its environment:
Part
Responsibility
How to test
Calculation
Allocation, rounding, and reconciliation rules
Fixed inputs, boundary values, and invariants
Data port
Read source positions and parameters
A double returns a prepared set of rows
Time or rate port
Determine a date, rate, or calendar
Explicit scenario values
Platform adapter
Call SAP tables, APIs, or functions
Integration check in a suitable system
Not every class needs an interface. Introduce a dependency boundary when a component changes independently, creates side effects, or prevents deterministic testing. Extra abstraction layers can make both code and tests harder to maintain.
With dependency injection, an object receives a collaborator through its constructor or a parameter instead of creating it inside a business method. A test can replace the production component with a stub, a fixed-response fake, or a mock. A stub supplies a known result; a mock can also verify an expected interaction. A double should express the scenario under test, not imitate the internal design of a real SAP component.
The ABAP OO Test Double Framework configures method behavior and can verify interactions. SAP documentation says it supports global interfaces, and global classes are supported on qualifying backend versions. It also lists restrictions, including local types and some class, constructor, and method types. Check the target system version and current restrictions before choosing this mechanism.
A small financial scenario: an allocation service receives eligible recipients from a data-provider interface. The test supplies two rows through a double, uses an amount of 101, runs the calculation, then checks recipient amounts, total conservation, and that persistence was not called. A separate integration test checks the read adapter and write behavior in the target system.
TEST-SEAM ... END-TEST-SEAM marks code that can be replaced by TEST-INJECTION during a test. It can help when gradually testing existing code that cannot yet be refactored safely. SAP documents limits: seams and injections must be in a suitable compilation scope; for example, test injections are limited to the same function pool, and reports do not support the mechanism.
A seam is useful as a local transition point. If a dependency is an important part of a class contract, an explicit interface is usually easier to discover and maintain. Avoid wrapping an entire method in a seam just to increase coverage; that can hide real behavior instead of testing it.
SAP documents a separate test double framework for function modules and states availability beginning with SAP NetWeaver AS ABAP 7.56. On an older system, an interface, seam, or another compatible mechanism may be needed. Do not assume availability across versions without checking.
Define the operation level of detail and input contract: currency, period, keys, precision, and missing-data behavior.
Test the calculation with an ordinary case, zero amount, negative amount, and conflicting keys.
Isolate time, rates, data reads, and platform calls where they affect the result or create side effects.
Confirm that the test double uses a public contract rather than private implementation details.
Run ABAP Unit and required integration checks in the target system and retain the actual report.
Items 1-4 are design guidance. Item 5 was not performed: this project has no connected ABAP system, so this page does not claim compilation, ABAP Unit, ATC, or runtime verification.
SAP Help documents individual ABAP Unit mechanisms and their version availability. It does not establish that the example above is implemented in an SAP repository, applies to every version, or was executed. The citations are retained as metadata; local text snapshots were not obtained.