A mio parere, i casi di test unitario servono come documentazione per il codice. La mia azienda vuole che scriva dettagliati commenti di documenti java in cima ai casi di test unitario. È necessario farlo? Scrivi commenti del genere?
A mio parere, i casi di test unitario servono come documentazione per il codice. La mia azienda vuole che scriva dettagliati commenti di documenti java in cima ai casi di test unitario. È necessario farlo? Scrivi commenti del genere?
Quello che faccio è JAVADOC-comment:
la classe, che indica quale classe è testata dall'unità (anche se dovrebbe essere ovvio poiché la migliore pratica su quell'argomento suggerisce che il nome del test case dovrebbe essere il nome della classe + "Test" o + "TestCase"). Questo viene fatto usando il {@link XXXClass} commento di JAVADOC
i metodi, che indicano quale metodo è testato ({@link XXXClass # method1}). A volte ho bisogno di avere più metodi di test per un metodo di una classe per testare correttamente tutti i percorsi. Quando succede, scrivo una riga aggiuntiva che indica quale percorso sto testando all'interno (ma non mi allontano mai dalla mia convenzione di una sola riga)
A parte questo, nessun altro commento. Per attirare la loro attenzione altrove forse potresti usare qualcosa come Cobertura per generare una bella grafica di copertura del codice e renderli felici in questo modo: -)
Nota aggiuntiva: mi riferisco ai casi di test unitario, se stiamo parlando di casi di test di integrazione, allora una o due righe per spiegare cosa sta succedendo potrebbe essere effettivamente necessario ...
I requisiti di documentazione per qualsiasi codice sono trattati in modo abbastanza completo nelle risposte a questa domanda: Il mio capo vuole una spiegazione inglese linea per linea del nostro codice
Come riassunto delle risposte vedrai lì, "Dipende dalla tua situazione". Ci sono casi in cui è ragionevole (e incoraggiato), e altri in cui è uno spreco di tempo.
I commenti Javadoc possono essere estratti e formattati in un documento di riferimento separato, i test unitari non possono. Inoltre, tieni presente che ciò che scrivi in parole può essere diverso dal codice vero e di solito stai descrivendo in parole il comportamento atteso. Uno dei modi per trovare i bug è confrontare la documentazione con il codice reale, se non corrispondono: si tratta di un bug (in entrambi, e talvolta - entrambi).
Il test unitario è per il test, non per la documentazione. Usare il test unitario come documentazione è sbagliato e non dovrebbe essere fatto.
Leggi altre domande sui tag unit-testing documentation