Il linguaggio di programmazione D supporta la scrittura di test di unità in linea con l'origine . C'è una gemma di Ruby chiamata test_inline che ti consente di scrivere specifiche nello stesso file del tuo codice.
Perché è generalmente convenzionale mantenere il codice sorgente in una directory completamente separata dal codice di test?
Prima di tutto, le specifiche e i test non sono sempre gli stessi. Soprattutto, i link che menzioni sono in realtà solo test unitari, cioè sono molto al di sotto del livello delle specifiche tipiche.
Ecco alcuni rimproveri per l'avvocato del tuo diavolo:
Riduce lo sforzo impiegato per passare da un file all'altro durante la modifica delle specifiche :
Stai scherzando, vero? Potremmo anche usare i nomi delle variabili a,b e c , perché riduce lo sforzo speso per la digitazione. Abbiamo molto più tempo da dedicare allo sviluppo del software che passare da un file all'altro. Questo non è davvero un argomento nel nostro caso, perché anche spiegarlo richiede più tempo di quello che si salva in un anno in cui lo si applica.
Facile da organizzare e mettere le specifiche accanto all'implementazione testata : alcuni IDE consentono di aprire il file di test dell'unità corrispondente dal file sorgente dell'applicazione. Inoltre, i test unitari sono posizionati accanto alle fonti testate, solo che accanto a significa all'interno dello stesso modulo . Una volta eseguiti i test di integrazione, che sono trasversali rispetto ai moduli, non è comunque possibile co-localizzarli con una qualsiasi delle fonti. Quindi, di nuovo, questo non è un vero argomento.
È facile incoraggiare le specifiche dell'unità con lo stesso file e le specifiche di integrazione in un altro file : questo è uno strano ragionamento qui. Vuoi avere unit test nello stesso file, perché ti incoraggia ad averli nello stesso file? Il ragionamento circolare non è molto popolare (specialmente con i manager di linea se capisci cosa intendo;))
L'uso di specifiche e sorgente insieme può aumentare la sensibilità sulle linee scritte : questo è in effetti qualcosa che vogliamo evitare. L'intero punto dello sviluppo basato su test è quello di scrivere i test senza nemmeno avere alcun codice sorgente, e una ragione per farlo è perché vogliamo testare su un livello diverso. Non vogliamo essere ingannati dall'effettivo codice di produzione in test di scrittura su misura per questo. I test dovrebbero funzionare per qualsiasi codice e la conoscenza di quel codice specifico può essere caricata solo su un test non valido.
In breve, molte persone apprezzano la separazione tra test e codice di produzione. Dopo tutto, la separazione significa che non spedisci il codice di prova. D'altra parte, come mostra il tuo ultimo argomento, mescolare i test con il codice può causare più danni che benefici, e nessuno dei tuoi argomenti è abbastanza convincente da farmi prendere in considerazione questa idea.
Modifica: sebbene tu abbia rimosso gli argomenti dell'avvocato del diavolo, il loro contro-ragionamento continua a spiegare perché non vogliamo farlo:
Inoltre, ci sono alcuni altri argomenti:
Separazione dal codice di produzione: il codice di prova per sua natura cerca di rompere le cose e questo lo rende qualcosa che la maggior parte delle persone preferisce non dare a un cliente. Inoltre, se non includi il codice di prova, finirai con un pacchetto più piccolo da consegnare (comunque non molto significativo).
Principio della singola responsabilità: se si include il codice di test all'interno della classe, si interrompe l'SRP, poiché la classe C ora è responsabile di X oltre a essere responsabile del test della classe C che sta eseguendo X correttamente. / p>
Controllo versione / Cronologia: le modifiche apportate al codice di produzione sono importanti e si desidera essere in grado di vedere rapidamente nella cronologia del proprio sistema di controllo della versione chi ha fatto cosa. Se la maneggi con i commit che riguardano solo il codice di test, hai molto più rumore.
Leggi altre domande sui tag tdd unit-testing code-organization