Esistono convenzioni per i nomi delle funzioni quando si utilizza Perl Test::More?

Question

Esistono convenzioni per i nomi delle funzioni quando si utilizzano i moduli Perl Test::More o Test::Simple?

Chiedo specificamente i nomi delle funzioni utilizzate per impostare un ambiente di test prima del test e per smontare l'ambiente dopo il completamento con successo dei test.

saluti,

rapinare

Answer 1

Non credo che esistano convenzioni del genere.

L'unico modo per farlo è forse utilizzare i blocchi BEGIN/END, se le risorse devono essere utilizzate sull'intero file.

L'approccio generale che seguo è quello di inserire i test correlati in un blocco di codice e quindi inizializzare lì le variabili/risorse ecc.Puoi forse tenere facilmente il conto di quanti test hai per ciascuna funzione.

Qualcosa di simile a ...

BEGIN {
   # If you want to set some global db setting/file setting/INC changes etc
}

# Tests functionality 1...
{
     # have fun .... 
}

# Tests functionality 2...
{
     # have more fun .... 
}

END {
   # Clean up the BEGIN changes
}

D'altra parte, potresti voler leggere questo per testare in perl ... http://perlandmac.blogspot.com/2007/08/using-perl-testsimple-and-testmore.html

Answer 2

Se stai cercando altri test in stile XUnit, dai un'occhiata Prova::Classe.Fornisce il Test(setup) E Test(teardown) attributi per metodi che, beh, configurano e demoliscono il tuo ambiente.Ti offre anche un modo molto più semplice di gestire i piani (puoi fornirne uno per ciascun metodo di test individualmente, quindi il conteggio è molto meno complicato) e ti consente di ereditare i test tramite gerarchie di classi di test.

Answer 3

Non penso che esista una serie ufficiale di convenzioni, quindi consiglierei di guardare gli esempi http://perldoc.perl.org/Test/More.html e vedere come scrivono i loro test.

Answer 4

Usiamo Test::Più ampiamente per i nostri test unitari poiché molti (la maggior parte) dei nostri script di elaborazione dati sono scritti in Perl.Non abbiamo una convenzione specifica per i nomi delle funzioni ma piuttosto facciamo qualcosa come suggerisce Jagmal, vale a dire suddividere i test in parti più piccole e inizializzarli localmente.

Nel nostro caso ogni sottotest è incapsulato in una funzione separata all'interno dello script di test.Oltre a questo abbiamo un framework che ci consente di eseguire tutti i sottotest (il test unitario completo) o di chiamare sottotest individuali o serie di sottotest per consentire l'esecuzione solo di quelli su cui stiamo lavorando al momento.

Answer 5

Grazie Espo.

Ho dato un'occhiata ai perldoc rilevanti ma non esiste una vera convenzione per quanto riguarda gli aspetti di installazione e smontaggio.

Non come la serie di test XUnit.

Grazie per la risposta Jagmal, ma non sono sicuro di utilizzare i blocchi BEGIN ed END per l'installazione e lo smontaggio poiché non stai chiarendo cosa stai facendo con i nomi.C'è anche l'ovvio problema di avere solo un'esecuzione di installazione e una di smontaggio per test, ad es.per ogni file .t.

Ho dato una rapida occhiata a Test::Most e sembra davvero interessante, soprattutto la funzione di spiegazione.Grazie Matt.

Hmm.Pensando ulteriormente all'utilizzo dei blocchi BEGIN ed END, penso che se diminuissi la granularità dei test in modo che siano necessari solo una configurazione e uno smontaggio, questa sarebbe una buona soluzione.

saluti,

rapinare

Answer 6

La prima convenzione che suggerirei è abbandonare Test::More per Test::Most

Answer 7

Gli script di test Perl non sono speciali o magici in alcun modo.In quanto tali, possono contenere esattamente le stesse cose di qualsiasi altro script Perl.

Puoi nominare le routine come preferisci e chiamarle prima, dopo e intrecciate con i tuoi test.

È possibile avere qualsiasi quantità di codice di inizializzazione prima di qualsiasi test, qualsiasi quantità di codice di pulizia dopo i test e qualsiasi quantità di qualsiasi altro codice mescolato ai test.

Tutto ciò presuppone che tu stia parlando di script di test t/*.t in stile CPAN.Penso di sì, ma riesco a leggere la tua domanda come una domanda sull'estensione dei cablaggi di prova, se strizzo gli occhi nel modo giusto.

Answer 8

Se sei disposto a partecipare anche ai test di accettazione, come Ruby's Cucumber, dai un'occhiata a questo piccolo esempio http://github.com/kesor/p5-cucumber che utilizza Test::More e uno stile di test di accettazione a cetriolo.