Risposta

In Perl, tradizionalmente si utilizza un pacchetto di moduli per i test: Test::Simple, Test::More, così come framework complessi come Test::Class, Test::Most. Il modulo di base è Test::More, che fornisce un ricco insieme di funzioni: verifiche di uguaglianza, confronti di strutture, test per eccezioni, e altro ancora.

Classificazione dei moduli popolari:

Test::Simple — per test molto semplici, iniziali;
Test::More — standard de facto per la maggior parte dei progetti;
Test::Exception, Test::Deep, Test::Warn — per controllare aspetti aggiuntivi (eccezioni, strutture nidificate, avvisi);
Test::Class, Test::Class::Moose — approcci orientati agli oggetti.

Esempio di test con Test::More:

use Test::More tests => 2;

is(2 + 2, 4, 'La somma funziona');
like('foo_bar', qr/foo/, 'Esiste foo');

Best practices:

Tutti i moduli pubblici devono avere test automatici nella directory t/-.
Non mescolare i dati di test con il codice di produzione.
Applicare test modulari, di integrazione, e a volte proprietà basate sui test.

Domanda trabocchetto

È possibile scrivere i propri test in Perl senza utilizzare i moduli Test::*, semplicemente usando le costruzioni die/print? Quali sono i rischi di tale approccio?

Risposta: Formalmente sì — è possibile scrivere i propri "test", usando print e die per l'output dei risultati. Tuttavia, in tal caso non si crea un approccio di automazione corretto: non si supportano integrazioni TAP/CPAN, è difficile creare report e analizzare un gran numero di test, e si complica la scalabilità e la manutenzione della base di test.

Esempio di test non riuscito:

print 'Moltiplicazione OK
' if multi(2,3) == 6;
die 'FAIL' if multi(2,0) != 0;

Esempi di errori reali a causa della mancanza di conoscenza dei dettagli dell'argomento

Storia

In un vecchio progetto, i test erano stati scritti "a mano" tramite die e print. Non era possibile integrare automaticamente la raccolta di moduli CPAN — gli script non restituivano stati chiari, il che faceva sì che gli errori di test venissero trascurati nelle release.

Storia

Il tentativo di mescolare l'uso di Test::Simple e Test::More senza considerare la struttura TAP (Test Anything Protocol) ha portato a un'uscita non corretta che ha danneggiato il sistema di test automatico. È stata necessaria una revisione dell'infrastruttura di test.

Storia

L'assenza di una buona copertura dei test di Test::Exception ha causato la mancata individuazione di una serie di errori nella gestione dei dati in ingresso: uno dei moduli non lanciava correttamente eccezioni, e questo non è stato rilevato durante i test, il bug è arrivato in produzione.