scrittura nomi dei metodi lungo test per descrivere i test vs utilizzando in documentazione del codice

Question

Per scrittura di unit test, so che è molto popolare per scrivere metodi di prova che assomigliano

public void Can_User_Authenticate_With_Bad_Password() 
{ 
... 
} 

Anche se questo rende più facile vedere ciò che il test sta provando, penso che sembri brutto e non si mostra bene nella documentazione generata automaticamente (come sandcastle o javadoc).

Sono interessato a vedere ciò che le persone pensano di utilizzare uno schema di denominazione che è il metodo in fase di test e underscore test e quindi il numero di test. Quindi utilizzare il documento del codice XML (.net) oi commenti di javadoc per descrivere ciò che viene testato.

/// <summary> 
/// Tests for user authentication with a bad password. 
/// </summary> 
public void AuthenticateUser_Test1() 
{ 
... 
} 

in questo modo posso facilmente raggruppare con quali metodi che stanno testando le mie prove, posso vedere come possono provare che ho per un dato metodo, e ho ancora una descrizione completa di ciò che è in fase di test.

abbiamo alcuni test di regressione eseguiti su un'origine dati (un file xml) e questi file possono essere aggiornati da qualcuno senza accesso al codice sorgente (scimmia QA) e devono essere in grado di leggere ciò che viene testato e dove, per aggiornare le fonti di dati.

Answer 1

Che dire cambiare

Can_User_Authenticate_With_Bad_Password 

a

AuthenticateDenieTest 
AuthenticateAcceptTest 

e il nome del vestito qualcosa come User

Answer 2

Personalmente preferisco usare i nomi dei metodi lunghi. Nota si può anche avere il nome del metodo all'interno della espressione, come:

Can_AuthenticateUser_With_Bad_Password() 

Answer 3

io preferisco la versione "nomi lunghi" - anche se solo per descrivere ciò che accade. Se il test ha bisogno di una descrizione di perché si verifica, lo inserirò in un commento (con un numero di errore se appropriato).

Con il nome lungo, è molto più chiaro ciò che è andato storto quando si riceve una mail (o qualsiasi altra cosa) che dice quali test hanno fallito.

vorrei scrivere in termini di ciò che dovrebbe fare però:

LogInSucceedsWithValidCredentials 

LogInFailsWithIncorrectPassword 

LogInFailsForUnknownUser 

non comprare l'argomento che sembra male nella documentazione generata automaticamente - il motivo per cui sono in esecuzione nel corso degli JavaDoc test in primo luogo? Non posso dire di averlo mai fatto, o voleva documentazione generata da. Dato che i metodi di test in genere non hanno parametri e non restituiscono nulla, se il nome del metodo può descriverli ragionevolmente sono tutte le informazioni necessarie. Il test runner dovrebbe essere in grado di elencare i test che esegue, o l'IDE può mostrarti ciò che è disponibile. Trovo che sia più comodo della navigazione via HTML - il browser non ha un "Tipo di ricerca" che mi consente di digitare solo le prime lettere di ogni parola del nome, ad esempio ...

Answer 4

Suggerisco più piccolo, più classi focalizzate (test).

Perché si desidera eseguire test javadoc?

Answer 5

Ha la documentazione presentarsi nel vostro test runner? Se no, questa è una buona ragione per usare invece nomi lunghi e descrittivi.

Personalmente preferisco i nomi lunghi e raramente vedo la necessità di aggiungere commenti ai test.

Answer 6

Come Gruppo Come ci sentiamo di fare un ibrido schema di denominazione come questo

/// <summary> 
/// Tests for user authentication with a bad password. 
/// </summary> 
public void AuthenticateUser_Test1_With_Bad_Password() 
{ 
... 
} 

e otteniamo il meglio di entrambi.

Answer 7

Ho fatto la mia tesi su un argomento correlato, quindi ecco i miei due centesimi: Ogni volta che ti affidi alla documentazione per trasmettere qualcosa che non è nella tua firma del metodo, stai assumendo l'enorme rischio che nessuno legga il documentazione.

Quando gli sviluppatori cercano qualcosa di specifico (ad esempio, eseguendo una scansione di un lungo elenco di metodi in una classe per vedere se quello che stanno cercando è già lì), la maggior parte di loro non si preoccuperà di leggere la documentazione. Vogliono trattare un tipo di informazioni che possono facilmente vedere e confrontare (ad esempio nomi), piuttosto che dover iniziare il reindirizzamento ad altri materiali (ad esempio, passare il mouse su un valore sufficientemente lungo da visualizzare JavaDocs).

Raccomanderei vivamente di trasmettere tutto ciò che è rilevante nella vostra firma.