Dove metti il ​​tuo test unitario?

Question

Ho trovato diverse convenzioni per i test delle unità di pulizia in un progetto e Non sono sicuro quale approccio sarebbe adatto per il nostro prossimo progetto PHP. Sono cercando di trovare la migliore convenzione per incoraggiare lo sviluppo facile e l'accessibilità dei test durante la revisione del codice sorgente. Sarei molto interessato a vostra esperienza/parere per quanto riguarda ciascuno:

1. Una cartella per il codice produttivo, un altro per i test unitari: Questo separa test di unità dai file di logica del progetto. Questa separazione delle preoccupazioni di è tanto più fastidiosa quanto un vantaggio: qualcuno che verifichi il codice sorgente del progetto, così suppongo, esaminerà l'implementazione oi test di unità (o più comunemente: solo l'implementazione ). Il vantaggio dei test unitari è un altro punto di vista per le classi è perso - questi due punti di vista sono solo troppo distanti IMO.
2. metodi annotati prova: Qualsiasi moderno quadro unit testing So permette agli sviluppatori di creare metodi di prova dedicati, indicandoli (@test) e incorporandoli nel codice di progetto. Il grosso inconveniente che vedo qui è che i file di progetto si ingombrano. Anche se questi metodi sono separati utilizzando un'intestazione di commento (come TEST UNITÀ sotto questa riga), basta gonfiare la classe inutilmente.
3. file di prova all'interno delle stesse cartelle come i file di implementazione: Il nostro file convenzione di denominazione impone che i file PHP contenenti classi (una classe per file) devono terminare con .class.php. Potrei immaginare che mettere le prove di unità per un file di classe in un altro che termina con .test.php rendere i test molto più presenti agli altri sviluppatori senza contaminare la classe . Anche se alleggerisce le cartelle di progetto, invece dei file di implementazione , questo è il mio preferito finora, ma ho i miei dubbi: I penserebbe che altri lo abbiano già fatto e scartato questa opzione per qualche motivo (ad es. non hanno visto un progetto Java con i file Foo.java e FooTest.java all'interno della stessa cartella.) Forse è perché gli sviluppatori Java fanno uso pesante di IDE che permettono loro un più facile accesso ai i test, mentre in PHP non sono emersi grandi editor (come eclipse per java) - molti sviluppatori che conosco usano vim/emacs o editor simili con il piccolo supporto per lo sviluppo PHP di per sé.

Qual è la vostra esperienza con uno di questi posizionamenti di test di unità? Hai un'altra convenzione che non ho elencato qui? O sto semplicemente sopravvalutando l'accessibilità ai test del unit test?

Answer 1

Io vado sempre per # 1. Mentre è bello che siano vicini. Le mie ragioni sono le seguenti:

• Ritengo che ci sia una differenza tra la base di codice principale e le unittests. Ho bisogno di una vera separazione.
• Gli utenti finali raramente hanno bisogno di esaminare gli unittest.Sono solo interessati all'API. Mentre è bello che le unittest forniscano una visione separata del codice, in pratica sento che non sarà usato per capirlo meglio. (più documentazione descrittiva + esempi).
• Poiché gli utenti finali raramente necessitano di unittests, non voglio confonderli con più file e/o metodi.
• I miei standard di codifica non sono la metà rigidi per le unittests così come lo sono per la libreria principale. Questa è forse solo la mia opinione, ma non mi interessa tanto per gli standard di codifica nei miei test.

Spero che questo aiuti.

Answer 2

Mi piace mantenere i test di unità in file di origine separati nella stessa directory del codice di produzione (n. 3).

I test di unità non sono cittadini di seconda classe, il loro codice deve essere mantenuto e refactored come il codice di produzione. Se si mantengono i test unitari in una directory separata, il prossimo sviluppatore per modificare il codice di produzione potrebbe perdere l'esistenza di test unitari e il mancato mantenimento dei test.

In C++, tendo ad avere tre file per classe:

MyClass.h 
MyClass.cpp 
t_MyClass.cpp 

Se stai usando Vim, allora la mia toggle_unit_tests plug-in per commutazione file di test di origine e di unità può rivelarsi utile.

Answer 3

L'attuale procedura migliore consiste nel separare i test di unità nella propria directory, n. Tutti i sistemi "convention over configuration" lo fanno così, ad es. Maven, Rails, ecc.

Penso che le tue alternative siano interessanti e valide, e il supporto degli strumenti è sicuramente lì per sostenerle. Ma non è così popolare (per quanto ne so). Alcune persone si oppongono all'esecuzione di test intercalati con il codice di produzione. Ma ha senso per me che se scrivi sempre unit test, che si trovano proprio con il tuo codice. Sembra solo più semplice.