Come it happens with private methods, la documentazione dei metodi di test delle unità può essere vista solo da chi ha accesso al codice sorgente. Vale la pena lo sforzo speso su di esso?Devo documentare i miei metodi di prova dell'unità?
da documentazione intendo qualcosa di simile (ma più descrittivo):
/// <summary>
///A test for SomeClass.SomeMethod
///</summary>
[TestMethod()]
public void SomeMethodTest()
{
}
Le prove unitarie dovrebbero mirare ad essere auto-descrittive, ma ci saranno sempre casi in cui questo obiettivo non può essere raggiunto e quindi la descrizione di ciò che è stato scritto è dovuta.
In altre parole, prova a fare i test di unità in modo che non abbiano bisogno di documentazione, ma se ne hanno bisogno, scrivilo!
avrei preferito essere propenso a dire che si dovrebbe assegnare un nome al metodo di prova in un modo che è espressiva quanto riguarda ciò che mette alla prova: SomeMethodWillBehaveThisWayWhenCalledWithTheseParameters() sebbene alcune persone possano trovarlo controverso.
Ho appena scoperto la denominazione "when_ * condition * _should_ * doThis *" per i metodi. –
Un nome descrittivo della funzione è utile ma inserire frasi complete è un po 'eccessivo per me. – stimpie
concordato. In genere, denominare i test delle unità utilizzando S/S/R: oggetto, scenario, risultato previsto.(http://blog.codeville.net/2009/08/24/writing-great-unit-tests-best-and-worst-practises/) In realtà non significa che non dovresti documentare il tuo codice. –
È necessario documentare tutto il codice.
Per i test di unità, di solito dico quello che sto testando, e come è stato testato. Mettere "Test per Class.someMethod" non è molto utile.
Oh sì!
Anche se "chi ha accesso al codice sorgente" non sarà mai più qualcun altro di te, non sarà lo stesso che lo guardi tra un anno (o anche un mese da oggi), fidati di me su quello :-)
+1 il maniaco maniaco omicida che sa dove vivi è probabilmente te stesso! – SingleNegationElimination
Penso che sia buono documentare i test di unità, il mio motivo principale è che si può spiegare perché viene testata una funzionalità specifica. I miei test unitari tendono a finire con tutti i tipi di strani parametri estremi o imprevisti.
Se un test non riesce, un programmatore futuro (o con una memoria errata) sa perché è stata testata/implementata una funzionalità.
Sì. I test possono sembrare auto-documentanti, ma le convoluzioni che devi attraversare a volte per generare dati di test significativi significa che tutto potrebbe non essere immediatamente ovvio per il manutentore finale, che potrebbe essere solo TU! Rendi la tua vita più facile - documenta il tuo codice.
Un test di unità dovrebbe essere abbastanza semplice e sufficientemente dettagliato da renderlo facilmente comprensibile. Se hai bisogno di commentare il test dell'unità, forse dovresti cambiare il suo nome, o forse dovresti rifattenerlo in metodi più piccoli.
Il test di refactoring è una buona pratica, è necessario refactoring i test in realtà, o diventeranno impossibili da mantenere.
I commenti come li vedo sono quasi sempre un segno che si dovrebbe refactoring quel pezzo di codice che è necessario commentare. Ciò che si applica al codice di produzione si applica al codice di prova.
La maggior parte dei test di unità non dovrebbe richiedere documentazione. Il nome dovrebbe chiarire quale metodo testano e fornire un'indicazione dei risultati attesi. Il codice dovrebbe essere semplice e chiaro. I test unitari non dovrebbero implementare le regole aziendali, quindi documentare il "perché" di solito non è necessario.
Nel raro caso in cui un test debba essere abbastanza complesso da giustificare i commenti, è necessario che siano documentati come qualsiasi altro codice.
Per MSTest (IDK se NUnit ha qualcosa di simile) è utile un DescriptionAttribute per ciascun metodo di test, poiché vengono visualizzati nel pannello Risultati del test su Visual Studio. Più leggibile della convenzione di denominazione WhenThisHappenShouldHappenThis.
Trovo che il messaggio stampato dal test dell'unità quando è in esecuzione sia generalmente sufficiente. Per esempio, in Perl:
is(compare_bitstrings($bs1, $bs2, $gen), 1, 'compare_bitstrings - bs1 > bs2');
Dà
ok 74 - compare_bitstrings - bs1 > bs2
quando viene eseguito con successo. Questo mi dice cosa sto cercando di fare e quale dovrebbe essere la risposta.
Buon punto, ma sappiamo che questo non vale per tutti i quadri di test unitari. –
Sì. La ragione per cui ritengo che documentare i test unitari sia una buona idea è che durante lo sviluppo, se modifichi non solo l'API delle tue classi di produzione, ma alcuni comportamenti interni che causano il fallimento di alcuni test, risparmia un po 'di tempo per navigare verso il prova il codice, leggi la documentazione del test unitario e verifica se ti aspettavi che il test fallisse dato il tuo recente cambio di comportamento o forse qualcosa di più sottile si sta verificando.
Senza questa documentazione si dovrebbe capire cosa fa il test dal suo nome e dai commenti/codice all'interno del test.
Si noti che se si desidera semplicemente riscrivere semplicemente il nome dell'unità test nella documentazione, questo non è molto utile e mi limiterei a dare al test dell'unità solo un nome descrittivo (cioè la documentazione dovrebbe essere più prolisso del nome del test unitario)
Assolutamente !! I tuoi test unitari dovrebbero essere documentati sia come codice effettivo che come codice. Se non altro per la circostanza non rara di non sapere se è il tuo codice o il tuo test che ha il bug.
Quando scrivo test, preferisco un commento per il test, seguito da un nome descrittivo del metodo di test (come il formato S/S/R menzionato nei commenti di un'altra risposta) perché è un'abitudine che i miei colleghi sviluppatori e io abbiamo in quando abbiamo iniziato con CPPUNIT con C++. Come mi diletto in C#, il punto menzionato da Lucas nella sua risposta è buono - quando il framework lo consente, il campo descrizione che può essere usato nel codice sorgente E risultati è molto utile, e io preferirei un commento formato che è utilizzabile in molti posti come quello.
Tutto ciò detto, penso che sia necessario considerare come il proprio team di sviluppo gestisce in genere i commenti di codice. La gente è nell'oscillazione generale in cui aggiornano i commenti quando il codice è riparato, refactored? Il progetto è più piccolo e avrà sempre gli stessi pochi sviluppatori che lavorano a stretto contatto?
I progetti su cui lavoro sono di dimensioni maggiori e, a seconda dello stato, possono essere gestiti da un team a stretto contatto, un team remoto o co-sviluppato o completamente consegnato a un fornitore. Nei miei scenari, cerchiamo di dedicare il tempo necessario per documentare e conservare la documentazione in produzione e codice di test per coloro che verranno in futuro.
Se i commenti sono di solito un ripensamento, per quanto possa darmi fastidio, se c'è una possibilità che i tuoi commenti non siano aggiornati con il codice/test effettivi, potrebbe non avere senso tentare di cambiare lo status quo.
A proposito, credo che tutto il codice dovrebbe mirare ad essere auto-descrittivo e avere commenti solo dove non sei riuscito a ottenere il codice per raccontare l'intera storia. I test unitari lo rendono più pronunciato (perché il codice di test unitario è in genere più semplice). –