I test JUnit devono essere eseguiti inavvertitamente?

Question

Ho un numero di casi di test JUnit che al momento non sono documentati con commenti Javadoc.

Il resto del mio codice è documentato, ma mi chiedo se valga la pena di documentare questi test.

Answer 1

Se lo scopo del test è ovvio, non mi preoccupo di documentarlo.

Se non è ovvio perché si tratta di una situazione oscura - o se voglio fare riferimento a un bug specifico, ad esempio - in quel aggiungerò documentazione. Non documento eccezioni, ecc., Solo un breve riassunto del metodo. Questo succede relativamente raramente. Sono più propenso ad aggiungere documentazione per i metodi di supporto utilizzati in più test.

Answer 2

Non trovo alcun valore nel javadocing dei casi di test. Rendo il nome del metodo abbastanza descrittivo da conoscere lo scopo del test.

In Ruby, so che ci sono strumenti per creare un documento dal nome dei test, ma non ne ho visto uno in Java.

Answer 3

Sia che javadoc o no, penso che i test unitari debbano essere sicuramente documentati. Nei casi in cui non esiste alcuna specifica formale, i test unitari sono ciò che si avvicina di più alla definizione del comportamento previsto del codice. Documentando i casi di test, chiarirai al lettore cosa sta testando il test e perché lo sta testando.

Answer 4

Quando si pensa ai test come documentazione, non ha molto senso "documentare la documentazione". Il nome di ciascun test dovrebbe già di per sé descrivere che qual è lo scopo dei test - qual è il comportamento specificato da quel test.

Utilizza nomi lunghi e descrittivi per i test e mantieni il codice di test il più leggibile possibile.

Ad esempio, dai uno sguardo ai casi di test in questo progetto . Qualcuno di loro fa qualcosa che non è palesemente ovvio guardando il nome dei test e il codice del test?

È solo in alcuni rari casi, quando il codice del test è oscuro, che nei test sono necessari commenti. Ad esempio, se si sta testando il codice multi-thread e il codice di test esegue operazioni strane per assicurarsi che il codice di test venga eseguito nell'ordine corretto. Ma anche in questi casi, un commento è una scusa per non aver scritto un codice di test più pulito.

Answer 5

Non vedo perché dovresti trattare i casi di test in modo diverso rispetto al tuo codice di produzione rispetto ai commenti.

Answer 6

Penso che sia prezioso per javadoc le condizioni in cui passano i test.

Answer 7

È un'eresia suggerire che i commenti sul codice sono un anti-pattern? Sono d'accordo con le risposte di cui sopra, idealmente il tuo codice sarebbe abbastanza descrittivo su cui fare affidamento senza commenti. Ciò è particolarmente vero se ci si trova in un ambiente (aziendale) in cui le persone tendono ad aggiornare il codice senza aggiornare i commenti, quindi i commenti diventano fuorvianti.

Answer 8

diavolo sì. anche se è solo ...

crea ordine, modifica ordine, salva, carica e amp; controllalo.

se è un test davvero semplice, forse no.

Trovo che quando il codice cambia, a volte il motivo del test non è ovvio come una volta.

Answer 9

Forse potresti avere qualcuno che non ha familiarità con il tuo codice per darti un rapido feedback sul fatto che i tuoi test siano facilmente comprensibili così come sono.

Nell'azienda per cui lavoro, proviamo a dare ai nostri test nomi descrittivi e complessità documentale, ma spesso è difficile ottenere questo "giusto". con la prima bozza perché le cose che sono ovvie per lo sviluppatore non sono sempre ovvie per gli altri.

I test sono trattati come un codice e inviati come parte di un processo di revisione tra pari in modo che il nostro (piccolo) team possa commentare se un test è facilmente comprensibile o meno.

Se un test è un po 'confuso, possiamo aggiornare il nome o la documentazione di conseguenza e veniamo via con un indicatore migliore di ciò che funziona e cosa no.