TAP: alcuni concetti

Il Test Anything Protocol (TAP per gli amici) è un formato semplice ed efficace per la reportistica di test automatici.
Nato nell'ecosistema Perl nel 1988, il protocollo si è evoluto ed è uscito dai confini Perl per giungere ad altri linguaggi e sistemi, perfino database con PostgreSQL e pgTap.

Il formato TAP è abbastanza semplice e si basa su alcuni concetti semplice:

• producer è un'applicazione che si occupa di produrre un output TAP compatibile (su stdout)
• consumer è un'applicazione che si occupa di interpretare l'output di un producer e fornire un report finale.

Ad esempio "prove" è un consumer dell'output prodotto da "Test::More" e similari, che a sua volta fungono da producer.
Nell'esempio relativo a PostgreSQL si ha che "pg_prove" è un consumer, e le funzioni importate da pgTap e i relativi script SQL sono i producer.

Il formato TAP è abbastanza semplice e prevede un solo paio di elementi obbligatori.
Anzitutto occorre inserire il numero di test, ovvero il piano di esecuzione, indicato come 1..N (con N > 0), e solitamente questo compare come primo elemento nell'output. Grazie a questa informazione il consumer sa se ha raggiunto la fine dei test (N) correttamente o se qualcosa ha causato un abort del sistema. Con l'evoluzione TAP supporta anche che N sia zero, indicando così che si vuole saltare la porzione di test. Inoltre è possibile specificare il piano di esecuzione alla fine, che in altre parole è come dire che non c'è un vero piano di esecuzione.

Successivamente, per ogni test effettuato, ci deve essere almeno una riga che inizia con "ok" oppure "not ok". Questo è l'unico elemento obbligatorio, anche se altri sono suggeriti per una migliore comprensione e analisi dei tool consumer.
Subito dopo lo stato del test si dovrebbe indicare il numero progressivo del test stesso, come pure una descrizione del test (affinché si possa capire meglio quale test è stato eseguito). Da ultimo vi è la possibilità di una direttiva (commentata in stile Perl, ossia con "#") che può indicare di saltare il test (SKIP) o che il test non è ancora completo (TODO).

Riassumento l'output di TAP può essere considerato come:


<# direttiva>

Ed ecco quindi un esempio pratico:

1..2
ok 1 - First comparison test
ok 2 - Second comparison


Qualora il piano di esecuzione non sia corretto TAP dovrebbe fornire una indicazione (non una direttiva) di tale fatto:

1..10
ok 1 - First comparison test
ok 2 - Second comparison
# Looks like you planned 10 tests but ran 2.

Solitamente durante la fase di sviluppo non si utilizza un piano di esecuzione, ma all'atto del rilascio del software il piano di esecuzione deve essere "congelato" in modo da aumentare la verifica automatica di errori.


Nell'output di TAP tutte le linee che iniziano con un commento in stile Perl ("#") vengono ignorate e usate, ad esempio, per fornire all'utente dei messaggi diagnostici per aiutarlo a capire perché un test è fallito.

Una direttiva di emergenza, denominata "Bail out!", indica che il sistema di test ha deciso di non proseguire per errori (controllati) troppo gravi. Ad esempio si può annullare una sessione di testing perché la rete non è disponibile, o il compilatore non è alla versione corretta, ecc.

Nel caso in cui non sia fornito un vero piano di esecuzione, e quindi l'output di TAP non inizi con "1..N", il sistema non sa quanti test deve eseguire. In questa eventualità si deve procedere con i test, aumentando in modo incrementale l'eventuale numero riportato in uscita, e alla fine stampando il "presunto" piano di esecuzione:

ok 1 - First comparison test
ok 2 - Second comparison
1..2

Tuttavia in questo caso il sistema non può sapere autonomamente se i test sono finiti o se c'è stato un abort di esecuzione, e per questo si richiede al programmatore di inserire una chiamata di fine esecuzione (ad esempio in Perl done_tsting() ).


Fino a qui ci si è occupati di TAP dal lato del producer. L'output di TAP viene poi analizzato a sua volta da un consumer, ad esempio "prove" o "pg_prove" che forniscono un riassunto su quanti test sono stati eseguiti, quanti sono andati bene e quanti sono falliti. L'idea dei consumer è che, all'aumentare del numero di test, l'utente dovrebbe potersi concentrare solo sul risultato finale e non sui singoli output dei vari test.

Per maggiori informazioni sulle specifiche TAP si veda qui.