I test delle unità dovrebbero essere archiviati nel repository?

Sicuramente dovresti mettere i test nel repository. I test sono a mio parere parte del codice e possono aiutare gli altri a capirlo immensamente (se ben scritti). Inoltre, possono aiutare gli altri quando cambiano o contribuiscono al tuo codice base. Buoni test possono darti la sicurezza che le tue modifiche non inavvertitamente interrompano nulla.

Il codice di test dovrebbe essere ben separato dal codice di produzione, però. Ad esempio, Maven realizza ciò inserendo il codice di produzione e di prova in diverse cartelle. La domanda "questo file parte della produzione o del codice di prova" non dovrebbe mai presentarsi.

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

Se non include i test unitari nel codice sorgente registrato, allora:

• come fa qualcuno che scarica e crea la propria copia di quel codice per verificare che funzioni come previsto? I bug del compilatore e della libreria sono rari e gli errori dei dati (in particolare quelli che non rendono il codice sorgente impossibile da compilare) sono ancora più rari, ma possono eliminarli, in particolare quando non è possibile dettare costruire l'ambiente nella misura in cui un datore di lavoro può dettare quali strumenti vengono utilizzati.
• come farai a riprendere i test se succede qualcosa alla tua copia locale del codice sorgente?
• in che modo un nuovo sviluppatore verificherà che le sue modifiche non infrangono nulla nella base di codice esistente?

In conclusione, prenderei in considerazione non compresi i test di unità scritti nel repository del codice sorgente ufficiale, cosa molto brutta.

Ovviamente dovresti mettere 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)

Se c'è qualche possibilità di eseguirli su un altro computer, includerli sicuramente. Dovrebbero essere compilati separatamente, quindi gli utenti non devono farlo e potrebbero avere delle dipendenze extra, ma dovrebbero essere sicuramente inclusi.

Sospetto strongmente che la maggior parte dei progetti che non includono test nel repository semplicemente non ne abbiano.

Potrebbe esserci un motivo per avere i test come modulo separato, quindi è possibile eseguire facilmente nuovi test contro il codice precedente. Sarebbe utile per librerie API-stable o test black-box via linea di comando; utilità per linguaggi compilati in cui i nuovi test probabilmente non verranno compilati con codice precedente è limitato.

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 e tirare i test appropriati progettati per quella versione (in caso di modifica dell'API o somesuch).

Ho appena finito di leggere "Sviluppo di applicazioni brownfield in .Net" , e questo fornisce alcuni consigli eccellenti della struttura di un'applicazione, incluso il controllo del codice sorgente e dove / come / perché includere i test di unità (in particolare nell'area dell'integrazione continua). Se sei uno sviluppatore .Net, lo consiglierei.