Gli Unit Test in Sme.UP

Quando si parla di sviluppo software, non si può non citare uno di quegli strumenti indispensabili che ogni “coltellino svizzero” di ogni buon programmatore dovrebbe contenere. Diamo quindi subito uno sguardo a cosa sono gli Unit Test e come vengono implementati in Sme.UP:

Unit Test

In prima battuta conviene specificare subito cosa è uno Unit Test e perchè è così importante.
Uno Unit Test è un insieme di condizioni o di variabili che vengono utilizzate per determinare se un’applicazione, un modulo o un intero sistema risponda correttamente o meno agli input inseriti. Più precisamente se a fronte di particolari ingressi ci sia un collegamento biunivoco tra l’aspettativa d’uscita e ciò che effettivamente viene restituito dal sistema.
In ambito generale questi test vengono svolti senza l’intervento di un operatore umano perché programmati per essere eseguiti autonomamente. Essi vengono utilizzati sia come riscontro sul fatto che una nuova applicazione (o parte di essa) funzioni come sperato, sia come metro di giudizio di un corretto refactoring o di integrazione di moduli. Altra caratteristica da non sottovalutare è anche il supporto che può dare alla documentazione in quanto incorpora l’utilizzo dell’API del modulo e ne identifica le corrette caratteristiche di funzionamento/fallimento che in taluni casi semplificano di molto la spiegazione del suo funzionamento.
Un’ottima metodologia utilizzata e che porta a numerosi vantaggi in ambito di Unit Test è la Test Driven Development (TDD). Esso prevede che vengano stesi gli Unit Test ancor prima di aver creato il codice per il programma, così da realizzare in seconda battuta lo sviluppo del software che avrà come obbiettivo il superamento dei test precedentemente predisposti.
Più dettagliatamente TDD prevede un breve ciclo di sviluppo articolato in tre fasi:

• Fase rossa: il programmatore scrive uno Unit Test per la nuova funzione che dovrà venir sviluppata e che dovrà fallire in quanto la parte software è ancora mancante;
• Fase verde: il programmatore scrive la minima parte di codice in grado di poter superare il test;
• Refactoring: il programmatore esegue il refactoring del codice per adeguare le funzionalità del software o per adattarlo a determinati standard di qualità.

Come funzionano in Sme.UP

In Sme.UP gli Unit Test vengono applicati alle API (chiamate anche /COPY) e non ai singoli programmi, e la massima importanza che Sme.UP dà a questa funzionalità la si evince nel fatto che seguendo la concezione della metodologia TDD, una API non può essere mandata in produzione senza aver prima creato lo Unit Test ad essa associata.

Solitamente in Sme.UP gli Unit Test sono così composti:
L’esecuzione di cosa questi test debbano fare è scritto all’interno di uno script denominato SCP_SIM che contiene delle istruzioni a cui vengono passati dei parametri di input (tra cui nome della sezione, se è una CAR, una DAT, una RDN ecc…) e l’output atteso.
In un SCP_CFG, che è un file di configurazione, vengono invece definite le interfacce di input/output delle singole /COPY.
Infine il programma che realmente esegue le operazioni sopra descritte è denominato B£SIM0_xxx (dove xxx stanno ad indicare il nome dell’API associata).
Per la creazione di questi script e programmi è possibile avvalersi dell’uso di utility che creano dei semilavorati da rifinire, (visionabile nell’immagine sottostante) che ricrea un semilavorato dell’API £G53.

Un esempio: API £DEC

Facciamo un esempio partendo da un’API semplice e conosciuta: la £DEC.
Essa prende in ingresso un oggetto di Sme.UP e ne restituisce la decodifica ed il controllo di esistenza, e i principali parametri di ingresso saranno il Codice, il Tipo ed il Parametro dell’oggetto (oltre ad altri valori come l’ambiente, data riferimento, ecc).

Nella sezione «Gestione» è possibile visualizzare lo script SCP_SIM (vedi immagine sottostante), indicante le istruzioni da eseguire, che in questo caso vengono divise in due blocchi separati.

Se volessimo effettuare uno Unit Test in maniera interattiva, si ha la possibilità di farlo recandosi nella sezione «Estemporaneo» e una volta inseriti i dati richiesti (segnati in giallo) come nell’esempio riportato qui sotto nella prima immagine, ed avendo dato conferma si avrà la possibilità di visualizzare l’output che viene generato a fronte degli ingressi inseriti (seconda immagine).

Se invece volessimo vedere l’effetto dell’esecuzione dei casi di test inseriti nell’SCP_SIM occorre lanciare un’istanza degli Unit Test andando nella sezione «Esecuzione» in cui verrebbe mostrata l’immagine sottostante. Qui possiamo trovare la sezione da lanciare tramite la combo box iniziale, ed è possibile flaggare tre ulteriori impostazioni tra cui:
– eseguire l’intero SCP_SIM senza tener conto dei blocchi o delle sezioni;
– visualizzare lo storico dei ristultati dei test precedenti, oltre a quello corrente;
– autocompletamento dei campi denominati “attesi” nell’SCP_SIM.

I risultati di questi test possono fallire o essere coerenti ed è possibile vederne un’applicazione nelle immagini sottostanti in cui la prima il test risulta Coerente ed ha inoltre lo storico, e la seconda in cui viene visualizzato il fallimento del test:

Nella sezione «Analisi» invece è possibile visualizzare l’esito degli ultimi test e la loro coerenza. Per completezza viene visualizzata sia l’immagine dei risultati della £DEC (prima immagine) sia quelli che si riferiscono al servizio JATRE_18C (seconda immagine).

Sempre nella stessa sezione (nel tab «Tendenza») si ha anche la possibilità di avere una rappresentazione grafica degli esiti dei test effettuati per avere a colpo d’occhio la riuscita o meno di una grande mole di dati.
Nelle immagini sottostanti per esempio possiamo notare come i test effettuati nella £DEC (prima immagine) risultino tutti Coerenti (passati), mentre i test effettuati sul servizio JATRE_18C (seconda immagine) risultino invece Coerenti solo alcuni di essi e Falliti gli altri.
Se si ha la necessità si può anche tramite la tabella sottostante, muoversi temporalmente per andare a verificare l’evento e i dati di input/output.

Importante precisazione degna di nota sta nel fatto che gli Unit Test vengano lanciati dall’ambiente designato per gli Unit Test.Questo perché ogni ambiente può contenere database differenti e con parametri che differiscono e che quindi potrebbero far risultare fallito un Test che invece nell’ambiente corretto risulterebbe coerente.

In caso si volesse approfondire l’argomento si rimanda alla documentazione:

• TA B£AMO A£MOPE