SAP ABAP Unit testing

SAP ABAP Unit Testing

Guida pratica per sviluppatori ABAP: dal framework di base alle architetture cloud moderne

Indice SAP ABAP Unit Testing

1. Introduzione: perché gli unit test in ABAP

2. Cos’è ABAP Unit: il framework integrato

3. Struttura degli unit test: componenti principali

4. Come si scrive un unit test ABAP: esempio essenziale

5. Gestione delle Dipendenze: Test Doubles

6. Come eseguire i test

7. Vantaggi degli unit test in ABAP

8. Criticità ed errori frequenti

9. ABAP Unit, Clean ABAP e ABAP Cloud (S/4HANA Cloud e SAP BTP)

10. Caso di studio: validazione di un calcolo di sconto

11. Novità e tendenze 2026-2027

12. Conclusioni e formazione professionale

1. Introduzione: perché gli unit test in ABAP – SAP ABAP Unit testing

Chiunque abbia lavorato su sistemi SAP sa quanto una modifica apparentemente innocua su un programma ABAP possa propagare errori a cascata in processi critici come la contabilità, la logistica o la gestione degli ordini. Eppure, ancora oggi, in molti team di sviluppo SAP la pratica degli unit test è assente o sporadica, affidata al buon senso del singolo sviluppatore piuttosto che a un processo strutturato e condiviso.

Gli unit test sono test automatici che verificano il corretto funzionamento di una singola unità di codice — tipicamente un metodo o una funzione — in modo isolato dal resto del sistema. Non sostituiscono i test di integrazione o i collaudi funzionali, ma li completano: intercettano i difetti il prima possibile, quando il costo di correzione è ancora minimo.

In ABAP, SAP ha integrato direttamente nel linguaggio e nel runtime un apposito framework chiamato ABAP Unit, che permette di scrivere, eseguire e analizzare questi test senza strumenti esterni. Implementarli non è solo una buona pratica: nelle moderne architetture ABAP Cloud e nei progetti di migrazione a S/4HANA, è diventato un requisito de facto per garantire codice di qualità, stabile agli upgrade e conforme ai principi del Clean Core.

2. Cos’è ABAP Unit: il framework integrato

ABAP Unit è l’implementazione del pattern xUnit — lo standard de facto per il testing automatico in molti linguaggi di programmazione — adattata al mondo ABAP. È integrato sia nel classico ABAP Workbench (SE80) che negli ABAP Development Tools (ADT) su Eclipse, e fa parte del runtime ABAP stesso: non richiede installazioni aggiuntive né licenze separate.

I test vengono scritti come classi locali all’interno della stessa unità di codice che contengono la logica da verificare, e vengono trasportati insieme al codice di produzione nei sistemi SAP. Il framework, tuttavia, garantisce che nessun codice di test possa essere eseguito in produzione o richiamato accidentalmente dal codice applicativo.

Per l’esecuzione su scala aziendale, ABAP Unit si integra con l’ABAP Test Cockpit (ATC), lo strumento di governance della qualità del codice disponibile anche su SAP BTP, che estende il testing con analisi statica, controlli di sicurezza e verifiche di conformità al modello Clean Core.

3. Struttura degli unit test: componenti principali – SAP ABAP Unit testing

Un test ABAP è strutturato come una classe locale speciale, identificata dall’addizione FOR TESTING nella sua dichiarazione. Ogni metodo che deve essere eseguito come test porta la stessa addizione. I componenti fondamentali del framework sono i seguenti.

Classe di test (Test Class): dichiarata con FOR TESTING, RISK LEVEL e DURATION. Il Risk Level (HARMLESS, DANGEROUS, CRITICAL) descrive l’impatto del test sui dati del sistema; DURATION (SHORT, MEDIUM, LONG) indica il tempo atteso di esecuzione. Questi attributi aiutano il framework a filtrare ed organizzare i test.

Metodi di test: sono i metodi della classe marcati con FOR TESTING. Non accettano parametri e comunicano il risultato esclusivamente tramite le asserzioni. I nomi devono essere quanto più descrittivi possibile: un buon nome di metodo di test racconta da solo cosa si sta verificando.

Metodi di fixture (ciclo di vita): il framework prevede quattro metodi speciali per gestire l’ambiente di test. CLASS_SETUP e CLASS_TEARDOWN vengono eseguiti una sola volta — rispettivamente all’inizio e alla fine dell’intera classe di test. SETUP e TEARDOWN vengono eseguiti prima e dopo ogni singolo metodo di test, garantendo che ogni test parta da uno stato pulito e definito.

CL_ABAP_UNIT_ASSERT: è la classe che fornisce i metodi per le asserzioni, ovvero le istruzioni che verificano se il comportamento del codice corrisponde all’aspettativa. I più utilizzati sono ASSERT_EQUALS (valore atteso = valore effettivo), ASSERT_NOT_INITIAL (la variabile non è vuota), ASSERT_BOUND (il riferimento non è nullo) e FAIL (forza il fallimento esplicito del test).

4. Come si scrive un unit test ABAP: esempio essenziale

Per rendere concreto il concetto, ecco uno snippet minimale. Il codice sotto test è un metodo che applica uno sconto del 5% se la quantità ordinata supera 50 unità; il test verifica entrambi i casi (sopra e sotto soglia):

CLASS ltc_sconto DEFINITION FINAL FOR TESTING

  RISK LEVEL HARMLESS DURATION SHORT.

  PRIVATE SECTION.

    DATA mo_cut TYPE REF TO zcl_sconto.

    METHODS: setup,

             sconto_se_qty_sopra_50 FOR TESTING,

             nessuno_sconto_se_qty_sotto_50 FOR TESTING.

ENDCLASS.

CLASS ltc_sconto IMPLEMENTATION.

  METHOD setup.

    mo_cut = NEW zcl_sconto( ).   " istanza fresca prima di ogni test

  ENDMETHOD.

  METHOD sconto_se_qty_sopra_50.

    cl_abap_unit_assert=>assert_equals(

      act = mo_cut->calcola_sconto( 100 )

      exp = '0.05' ).

  ENDMETHOD.

  METHOD nessuno_sconto_se_qty_sotto_50.

    cl_abap_unit_assert=>assert_equals(

      act = mo_cut->calcola_sconto( 30 )

      exp = '0.00' ).

  ENDMETHOD.

ENDCLASS.

Tre elementi vanno notati in questo snippet. Primo: la variabile mo_cut è chiamata CUT, acronimo di Code Under Test — una convenzione diffusa che rende immediato identificare l’oggetto sottoposto a verifica. Secondo: il metodo SETUP ricrea l’istanza prima di ogni test, eliminando qualsiasi stato residuo. Terzo: i nomi dei metodi di test descrivono un comportamento, non una procedura: chi legge il codice capisce immediatamente cosa viene verificato e in quale condizione.

5. Gestione delle Dipendenze: Test Doubles

Uno degli aspetti più delicati nello scrivere unit test è l’isolamento: il codice sotto test non deve dipendere da elementi esterni — database, RFC, API di sistema — perché renderebbe i test lenti, instabili e dipendenti da dati che potrebbero cambiare. La soluzione è il Test Double: un oggetto sostitutivo che simula il comportamento della dipendenza reale durante l’esecuzione del test.

In ABAP esistono più strumenti per creare Test Double, a seconda del tipo di dipendenza da sostituire.

Test Double manuale: si implementa manualmente un’interfaccia con comportamenti predefiniti (hardcoded). È il metodo più trasparente e didattico, ideale per iniziare.

CL_ABAP_TESTDOUBLE (ABAP Test Double Framework): SAP fornisce questo framework che genera Mock Objects dinamicamente a runtime, permettendo di configurare valori di ritorno e aspettative senza implementare manualmente l’interfaccia.

IF_OSQL_TEST_ENVIRONMENT: per testare codice con SELECT su tabelle DB, permette di popolare dati in memoria senza accedere al database reale. I dati vengono definiti nel test e isolati completamente.

IF_CDS_TEST_ENVIRONMENT: dedicato ai progetti ABAP Cloud e RAP, permette di iniettare dati di test nelle CDS views senza toccare il database sottostante.

Il prerequisito architetturale per usare qualsiasi Test Double è la Dependency Injection: le dipendenze devono essere passate alla classe dall’esterno — tipicamente tramite il costruttore — e non create internamente con istruzioni hardcoded. Un codice testabile è, prima di tutto, un codice disaccoppiato.

6. Come eseguire i test

L’esecuzione degli unit test ABAP può avvenire in diversi modi, a seconda del contesto e della scala desiderata.

In ADT (Eclipse), il metodo più rapido è selezionare una classe o un package nel Project Explorer e premere Ctrl+Shift+F10 (oppure “Run As > ABAP Unit Test”). I risultati appaiono nella ABAP Unit view con un semaforo verde/rosso per ogni metodo, il messaggio di errore in caso di fallimento e la percentuale di copertura del codice (Code Coverage).

Nel classico ABAP Workbench (SE80), i test si eseguono dal menu Programma > Test > Unit Test. È la modalità per chi lavora ancora su sistemi on-premise con strumenti tradizionali.

L’ABAP Unit Browser consente di eseguire test su larga scala — interi package o componenti software — ed è utile per i test run massivi da effettuare prima di un trasporto verso QA o produzione.

L’ABAP Test Cockpit (ATC) è lo strumento enterprise. Integra ABAP Unit e aggiunge analisi statica, Code Vulnerability Analyzer e verifiche di conformità Clean Core. In S/4HANA Cloud e SAP BTP è lo strumento raccomandato per la governance del codice custom, con la possibilità di bloccare automaticamente i trasporti in presenza di violazioni di Priority 1 e 2. Un obiettivo realistico nei team maturi è mantenere almeno il 70-80% di code coverage sulle classi di business logic critiche.

7. Vantaggi degli unit test in ABAP

Adottare una cultura degli unit test in ABAP produce benefici concreti e misurabili in ogni fase del ciclo di sviluppo.

Il vantaggio più immediato è l’individuazione precoce dei difetti: i bug emergono durante lo sviluppo, quando correggerli costa pochi minuti, invece che in produzione, dove una hotfix urgente può richiedere giorni e generare danni operativi. La sicurezza durante il refactoring è altrettanto preziosa: quando si ristruttura il codice, si migra da ABAP classico ad ABAP Cloud o si aggiorna la logica di business, la suite di test esistente certifica che il comportamento esterno non sia cambiato.

I test ben nominati sono anche una forma di documentazione vivente: descrivono in modo preciso e sempre aggiornato i comportamenti attesi del codice. A differenza di un documento Word, non possono diventare obsoleti, perché vengono eseguiti ad ogni ciclo di sviluppo.

Sul piano strategico, gli unit test abilitano pipeline CI/CD nel mondo SAP — con strumenti come gCTS (Git-enabled Change and Transport System) e ABAP Build Framework — e garantiscono upgrade-safety negli ambienti S/4HANA Cloud Public Edition, dove SAP rilascia aggiornamenti automatici ogni sei mesi. Disporre di test automatici significa poter verificare in ore, invece che in settimane, che le customizzazioni non siano state impattate dall’upgrade.

8. Criticità ed errori frequenti

Conoscere in anticipo le criticità più comuni aiuta ad evitarle. Il primo errore è scrivere test che accedono direttamente al database con SELECT su tabelle reali: questi test sono lenti, dipendono dai dati presenti nel sistema e producono risultati non deterministici. La soluzione è usare i Test Environment framework di SAP (OSQL o CDS) per lavorare con dati in memoria.

Il secondo problema è più strutturale: codice non progettato per la testabilità. Classi con dipendenze hardcoded — SELECT embedded nella business logic, chiamate dirette a classi concrete invece di interfacce — sono di fatto non testabili senza un refactoring preliminare. È un problema di design architetturale prima ancora che di testing.

Sul piano della scrittura dei test, gli errori più frequenti sono: nomi di metodi non descrittivi (test_01, prova_sconto), che non comunicano nulla sull’intenzione del test; copertura del solo happy path, trascurando valori limite, input errati ed eccezioni attese; test con dipendenze reciproche che funzionano solo se eseguiti in un certo ordine — mentre il framework ABAP Unit esegue i metodi in ordine non determinato, rendendo tali test intrinsecamente fragili.

Infine, una criticità organizzativa: i test scritti senza una convenzione condivisa nel team producono una suite disomogenea, difficile da leggere e da mantenere. La coerenza stilistica è tanto importante quanto la copertura.

9. ABAP Unit, Clean ABAP e ABAP Cloud

Il movimento Clean ABAP — codificato nella guida ufficiale SAP disponibile su GitHub e nel volume Clean ABAP di SAP PRESS — pone il testing al centro della qualità del codice. I principi Clean ABAP incoraggiano classi brevi, metodi con responsabilità singola, dipendenze iniettabili e interfacce ben definite: tutte caratteristiche che rendono il codice naturalmente testabile con ABAP Unit. Non a caso, la testabilità è considerata uno dei criteri di valutazione primari del codice ABAP di qualità.

In ottica ABAP Cloud — il modello di sviluppo per SAP BTP ABAP Environment, S/4HANA Cloud Public Edition e Private Edition — gli unit test assumono un ruolo ancora più strategico. La filosofia Clean Core richiede che il codice custom sia disaccoppiato dal core SAP, upgrade-stable e fondato su API rilasciate (Released APIs). Gli unit test, combinati con l’ABAP Test Cockpit, sono lo strumento principale per dimostrare e mantenere nel tempo questa conformità.

Nell’agosto 2025 SAP ha aggiornato le linee guida introducendo il modello Clean Core Extensibility. In questo framework, l’ATC su SAP BTP è diventato il punto di governance raccomandato per tutti gli sviluppi ABAP — on-premise e cloud — con la possibilità di bloccare automaticamente i trasporti in presenza di violazioni critiche. Per le architetture RAP (ABAP RESTful Application Programming Model), il framework CL_CDS_TEST_ENVIRONMENT permette di testare i Business Objects in isolamento completo, sostituendo le CDS views con dati mock e rendendo testabili anche le logiche transazionali più complesse.

10. Caso di studio: validazione di un calcolo di sconto

Una società ha implementato una classe ZCL_PRICING_ENGINE con un metodo get_discount_rate che applica sconti differenziati in base alla categoria cliente e alla quantità ordinata. Il metodo legge la configurazione da una tabella custom tramite un’interfaccia repository (ZIF_DISCOUNT_REPO). L’obiettivo è verificare la logica di calcolo senza accedere al database.

La soluzione adotta il pattern Dependency Injection: il Test Double dell’interfaccia repository restituisce dati mock, e viene iniettato nel costruttore della classe sotto test:

" Test Double — simula il repository senza DB

CLASS ltd_repo DEFINITION FOR TESTING.

  PUBLIC SECTION. INTERFACES zif_discount_repo.

ENDCLASS.

CLASS ltd_repo IMPLEMENTATION.

  METHOD zif_discount_repo~get_config.

    rs_config = VALUE #( threshold = 100  discount = '0.10' ).

  ENDMETHOD.

ENDCLASS.

" Classe di test

CLASS ltc_pricing DEFINITION FOR TESTING RISK LEVEL HARMLESS DURATION SHORT.

  PRIVATE SECTION.

    DATA mo_cut TYPE REF TO zcl_pricing_engine.

    METHODS: setup, sconto_cat_A_sopra_soglia FOR TESTING.

ENDCLASS.

CLASS ltc_pricing IMPLEMENTATION.

  METHOD setup.

    mo_cut = NEW zcl_pricing_engine( io_repo = NEW ltd_repo( ) ).

  ENDMETHOD.

  METHOD sconto_cat_A_sopra_soglia.

    cl_abap_unit_assert=>assert_equals(

      act = mo_cut->get_discount_rate( iv_customer_cat = 'A'  iv_quantity = 150 )

      exp = '0.10' ).

  ENDMETHOD.

ENDCLASS.

Il test viene eseguito in millisecondi, senza dati reali, ed è completamente riproducibile in qualsiasi sistema (DEV, QA, pipeline CI). Se domani la logica di calcolo viene modificata per errore, il test fallirà immediatamente evidenziando la regressione prima che arrivi in produzione.

11. Novità e tendenze 2026-2027

Il panorama del testing ABAP sta evolvendo su tre fronti convergenti. Il primo è l’intelligenza artificiale generativa: Joule, l’assistente AI integrato negli ambienti ABAP Cloud, è già in grado di generare scheletri di test e suggerire Test Double per le classi analizzate. SAP ha dichiarato che la generazione automatica di unit test è tra le funzionalità prioritarie nei rilasci 2025-2026, con l’obiettivo di abbattere la barriera d’ingresso per i team che non hanno ancora adottato il testing sistematico.

Il secondo fronte è l’integrazione nativa con pipeline CI/CD: l’ABAP Build Framework (disponibile da SAP_BASIS 7.50+) permette di integrare l’esecuzione di ABAP Unit test in workflow automatizzati, pubblicando i risultati in formato JUnit-compatibile — leggibile da qualsiasi sistema di CI come Jenkins o Azure DevOps. Questo abilita scenari DevOps completi anche per lo sviluppo ABAP, un cambio culturale significativo per un ecosistema tradizionalmente orientato ai trasporti manuali.

Il terzo fronte è la governance centralizzata: entro il 2027 SAP prevede che l’ATC su SAP BTP diventi lo standard unico per la qualità del codice ABAP — on-premise e cloud — con nuove check suite integrate direttamente nel flusso quotidiano di sviluppo. La direzione è chiara: il testing non sarà più un’attività opzionale post-sviluppo, ma una componente obbligatoria e automatizzata del ciclo di vita del software SAP.

12. Conclusioni e formazione professionale

Gli unit test in SAP ABAP non sono un lusso riservato ai grandi team o ai progetti cloud: sono una pratica essenziale per qualsiasi sviluppatore che voglia produrre codice affidabile, manutenibile e pronto per le evoluzioni del panorama SAP. La capacità di isolare, testare e verificare automaticamente ogni unità di logica è la differenza concreta tra un codice che sopravvive agli upgrade e uno che li teme.

Ma c’è un aspetto che spesso viene sottovalutato: la sola disponibilità del framework non basta. Il vero ostacolo all’adozione degli unit test nei team SAP non è tecnico — il framework è lì, pronto all’uso — ma culturale e formativo. Senza una formazione strutturata e uniforme, ogni sviluppatore tende ad applicare le proprie regole, o a non applicarne affatto, generando una qualità del codice disomogenea che nel lungo periodo si accumula come debito tecnico difficilmente sanabile.

Solo un’eccellente formazione del personale IT garantisce un impiego uniforme e corretto degli unit test in SAP ABAP. Solo la formazione costruisce quella cultura della qualità che si traduce in standard elevati per l’intero team: meno bug in produzione, meno tempo speso in debug, più fiducia nei rilasci, maggiore sostenibilità del codice nel tempo. Investire nella formazione degli sviluppatori ABAP è, prima ancora che una scelta tecnica, una decisione strategica per il business.

Formare il tuo team con Innovaformazione

Innovaformazione eroga il Corso SAP ABAP Programmatore, pensato per aziende che vogliono formare o aggiornare i propri sviluppatori ABAP — sia alle prime armi che con esperienza pregressa. Il corso SAP ABAP standard è base, copre le fondamenta del linguaggio ma è possibile richiedere un corso personalizzato fino alle tecniche moderne come il testing con ABAP Unit.

Modalità: online, in classe virtuale, con calendario concordabile in base alle esigenze aziendali. I contenuti possono essere personalizzati per adattarsi al contesto specifico del team e del progetto SAP.

Finanziamento: Innovaformazione supporta le aziende nel piano formativo finanziato tramite Fondimpresa, permettendo di formare i propri dipendenti a costo zero accedendo ai fondi interprofessionali disponibili per la formazione continua.

Contatti

Per richiedere un preventivo o informazioni:

info@innovaformazione.net – tel. 3471012275 (Dario Carrassi)

Per altri articoli sul mondo SAP consigliamo di navigare nella sezione dedicata del nostro blog QUI.

(fonte) (fonte) (fonte)