ASP.net MVC RTM Convenzioni di denominazione del test

Question

Sto lavorando su un'applicazione asp.net mvc e sto scrivendo il mio apparecchio per il test BDD. Es.

GetResource_WhenResourceFileExists_ShouldReturnResources()

ma quando scrivo i test per i miei controllori, di solito ho due metodi con lo stesso nome. Uno senza parametri per ottenere richieste e uno con per i messaggi. Qualcuno ha una buona convenzione di denominazione qui per distinguere tra i due?

mi viene in mente:

1. 
LogIn_WithParameters_ShouldReturnLogInView() 
LogIn_WithoutParameters_WhenAuthenticationFailed_ShouldReturnLogInView() 
LogIn_WithoutParameters_WhenAuthenticationPassed_ShouldReturnProfileRedirect() 

2. 
LogIn_Get_ShouldReturnLogInView() 
LogIn_Post_WhenAuthenticationFailed_ShouldReturnLogInView() 
LogIn_Post_WhenAuthenticationPassed_ShouldReturnProfileRedirect() 

3. 
LogIn_ShouldReturnLogInView() 
LogIn_WhenCalledWithParametersAndAuthenticationFailed_ShouldReturnLogInView() 
LogIn_WhenCalledWithParametersAndAuthenticationPassed_ShouldReturnProfileRedirect() 

Tutte le opinioni?

Answer 1

Penso che questo sia un perfetto esempio del perché le convenzioni di denominazione rigide per i test di unità non siano interessanti.

Lo schema proposto funzionerà solo quando si verificano due overload di metodo: uno con e uno senza parametri. Non si estende allo scenario in cui si ha più di un sovraccarico con parametri diversi.

Personalmente preferisco una convenzione di denominazione molto più flessibile che si può riassumere come

[Action][Will|Should|Is|...][Result] 

Questo mi dà la possibilità di nominare i miei test

SutIsPathResolutionCommand 
ExecuteWithNullEvaluationContextWillThrow 
ExecuteWillAddDefaultClaimsTransformationServiceWhenNoConnectionServiceIsAvailable 

devo ammettere che raramente letto il nome di il test comunque. Invece, leggo le specifiche di ciò che fa (cioè il codice di test). Il nome non è così importante per me.

Answer 2

Io uso il seguente formato che funziona molto bene per me:

[TestFixture]  
public class Log_in_with_parameters_should 
{ 
    [Test] 
    public void Return_the_log_in_view() {} 
} 

[TestFixture]  
public class Log_in_without_parameters_should 
{ 
    [Test] 
    public void Return_the_log_in_view_when_the_authentication_failed() {} 

    [Test] 
    public void Redirect_to_the_profile_when_the_authentication_passed() {} 
} 

Answer 3

Una possibilità, che non mi piace particolarmente, è quello di dare le azioni di controllo nomi diversi, ma per poi rinominarli utilizzando il ActionName attributo:

public ActionResult Login() { 
    // ... code ... 
    return View(); 
} 

[HttpPost] 
[ActionName("Login")] 
public ActionResult LoginPost(... some params ...) { 
    // ... more code ... 
    return View(); 
} 

Questo sostituisce essenzialmente un problema (unità di prova denominazione) con un altro problema (difficile da leggere il codice di controllo). Ciononostante, potresti trovare questo schema attraente poiché risolve il problema dichiarato.

Answer 4

Potrei non rispondere alla tua domanda, ma voglio condividere quello che faccio. Non seguo specifiche convenzioni di denominazione, ma cerco di fornire dei nomi che spieghino che metodo di prova sta provando a testare. Alcuni casi in cui ho bisogno di ulteriori spiegazioni, aggiungo la descrizione [Test ("Questo test valuta quante domande hanno ricevuto risposta da un utente specifico")].

Una cosa per assicurarsi che i test siano più leggibili e rapidamente comprensibili.

Answer 5

Io uso una convenzione di denominazione simile a quello nella tua domanda cioè method_scenario_expected penso che si dovrebbe elaborare più sulla parte "scenario" - se si sta passando i parametri - lasciare che il lettore sa che cosa è speacial su di loro .

Ricordare che denominare i test in questo modo è più "TDD oreinted" e nessun BDD - I nomi dei test BDD dovrebbero riguardare regole e "comportamenti :.

Se ritieni che l'attuale convenzione di denominazione non guidi la leggibilità del codice, sentiti libero di sperimentare e trovare ciò che funziona per te.