I test unitari devono essere archiviati nel repository?

50

Sono un programmatore in crescita che sta finalmente mettendo in pratica i test unitari per una libreria che sto memorizzando su GitHub.

Mi è venuto in mente che avrei potuto includere le suite di test nel repository, ma mentre mi guardo intorno ad altri progetti, l'inclusione dei test sembra incostante.

Questa è considerata una cattiva forma? L'idea è che gli utenti siano interessati solo al codice di lavoro e che comunque testeranno nel proprio framework?

version-control unit-testing

— parisminton
fonte

13

Perchè no? I test dovrebbero arrivare insieme al progetto o sono a mala pena inutili.

61

Il fatto che alcuni progetti non includano unit test nel loro repository è più probabile a causa della non esistenza di questi test in primo luogo.

— prasopes il

4

Sono costruiti separatamente, ma per il resto gli u-test sono strettamente associati al codice. Per garantire la coerenza è necessario un qualche tipo di gestione delle dipendenze. Indipendentemente dal fatto che li inseriscano nello stesso repository, sottorepository o versione di maintaing controllata "link" per testare il repository, ecc.

— MaR

2

@stoupa ha decisamente ragione: sarebbe bello assumere il meglio, che da qualche parte c'è una meravigliosa cache di test nascosti, ma nel mondo reale i programmatori sono pigri.

— Cascabel,

2

Si noti che considererei una buona idea disabilitare la compilazione della classe di test nello script di compilazione.

— user606723

119

Dovresti assolutamente mettere i tuoi test nel repository. I test fanno parte del codice e possono aiutare gli altri immensamente a capirlo (se ben scritto). Inoltre, possono aiutare gli altri quando cambiano o contribuiscono alla tua base di codice. Buoni test possono darti la certezza che le tue modifiche non infrangono inavvertitamente nulla.

Tuttavia, il codice di prova dovrebbe essere ben separato dal codice di produzione. Maven, ad esempio, ottiene questo risultato inserendo codice di produzione e test in diverse cartelle. La domanda "fa parte del file di produzione o del codice di prova" non dovrebbe mai sorgere.

Personalmente non scrivo unit test per le librerie usate nel mio codice. Mi aspetto che funzionino (almeno quando uso una versione di rilascio, anche se ovviamente possono apparire dei bug). Ottiene una certa copertura nei test di integrazione, ma non è abbastanza.

— FTR
fonte

1

Come altro esempio, dai un'occhiata alla cartella dei test di ipython . Se qualcuno lo verifica, non importa dove lo metta, i collegamenti relativi per i test sono ancora veri. È banale testarlo, il che è importante per determinare se la tua nuova macchina di sviluppo è configurata correttamente.

— Spencer Rathbun il

I test non fanno solo parte del codice, ma fanno anche parte della documentazione e spesso fanno parte delle specifiche. I test (che corrono e passano) sono "documentazione vivente".

— Michael Easter,

54

Se non includi i test unitari nel codice sorgente archiviato, allora:

in che modo qualcuno che scarica e crea la propria copia di quel codice verificherà che funzioni nel modo previsto? I bug del compilatore e della libreria sono rari e gli errori di dati (in particolare quelli che non rendono impossibile compilare il codice sorgente) sono ancora più rari, ma possono sicuramente insinuarsi, in particolare quando non è possibile dettare l'ambiente di costruzione nella misura in cui un il datore di lavoro può stabilire quali strumenti vengono utilizzati.
come hai intenzione di riavere i test se succede qualcosa alla tua copia locale del codice sorgente?
in che modo un nuovo sviluppatore verificherà che le sue modifiche non interrompano nulla nella base di codice esistente?

In conclusione, prenderei in considerazione l'idea di non includere alcun test unitario scritto nel repository ufficiale del codice sorgente.

— un CVn
fonte

7

Ovviamente dovresti inserire unit test nel repository, per diversi motivi:

è facile tornare alla versione precedente
anche altre persone che lavorano al progetto hanno accesso ai test unitari
alcune persone considerano i test unitari come parte della documentazione (TDD e BDD)

— BЈовић
fonte

6

Se esiste la possibilità di eseguirli su un altro computer, includerli sicuramente. Dovrebbero essere costruiti separatamente, quindi gli utenti non devono e potrebbero avere dipendenze extra, ma dovrebbero essere sicuramente inclusi.

Sospetto fortemente che la maggior parte dei progetti che non includono test nel repository semplicemente non ne abbia.

Potrebbe esserci un motivo per avere i test come modulo separato, in modo da poter eseguire facilmente nuovi test su codice più vecchio. Sarebbe utile per test di libreria o black box stabili all'API tramite riga di comando; l'utilità per i linguaggi compilati in cui i nuovi test probabilmente non verranno compilati con codice precedente è limitata.

— Jan Hudec
fonte

5

Assolutamente. I punti bonus extra qui sono nella capacità di tracciare che la versione X di un file sorgente va con la versione Y di un test. In altre parole, devi essere in grado di tornare a una versione precedente ed eseguire i test appropriati progettati per quella versione (in caso di modifica dell'API o altro).

— subito
fonte

3

Ho appena finito di leggere "Brownfield Application Development in .Net" , e questo fornisce alcuni eccellenti consigli sulla struttura di un'applicazione, incluso il controllo del codice sorgente e dove / come / perché includere test unitari (in particolare nell'area dell'integrazione continua) . Se sei uno sviluppatore .Net, lo consiglierei.

— seanfitzg
fonte