ASP.NET MVC RTM Test Namenskonventionen

Question

Ich arbeite an einer asp.net mvc-Anwendung und schreibe meine Unit-Tests BDD-Stil. Eg.

GetResource_WhenResourceFileExists_ShouldReturnResources()

Aber wenn ich Tests für meinen Controller schreibe, ich habe in der Regel zwei Methoden mit dem gleichen Namen. Eine ohne Parameter für Get-Anfragen und eine mit für Posts. Hat jemand hier eine gute Namenskonvention, um zwischen den beiden zu unterscheiden?

kann ich mir vorstellen:

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() 

Irgendwelche Meinungen?

Answer 1

Ich denke, dies ist ein perfektes Beispiel dafür, warum starre Namenskonventionen für Komponententests unattraktiv sind.

Ihr vorgeschlagenes Schema funktioniert nur, wenn Sie zwei Methodenüberladungen haben: eins mit und eins ohne Parameter. Es erstreckt sich nicht auf das Szenario, in dem Sie mehr als eine Überladung mit verschiedenen Parametern haben.

Persönlich bevorzuge ich eine viel lockere Namenskonvention, die zusammengefasst werden kann als

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

Das mir die Flexibilität gibt, meine Tests

SutIsPathResolutionCommand 
ExecuteWithNullEvaluationContextWillThrow 
ExecuteWillAddDefaultClaimsTransformationServiceWhenNoConnectionServiceIsAvailable 

Ich muß zugeben nennen, dass ich lese selten den Namen der Test jedenfalls. Stattdessen lese ich die Spezifikation dessen, was es tut (d. H. Der Testcode). Der Name ist für mich nicht so wichtig.

Answer 2

Ich benutze das folgende Format, das für mich sehr gut funktioniert:

[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

Eine Option, die ich nicht besonders gut gefällt, ist die Controller-Aktionen verschiedene Namen zu geben, aber benennen sie die Verwendung von ActionName Attribut:

Dies ersetzt im Wesentlichen ein Problem (Komponententest) mit einem anderen Problem (schwerer zu lesen Controller-Code). Nichtsdestoweniger mag dieses Muster ansprechend sein, da es das angegebene Problem löst.

Answer 4

Ich beantworte deine Frage vielleicht nicht, aber ich möchte teilen, was ich tue. Ich folge nicht bestimmten Namenskonventionen, aber ich versuche Namen zu geben, die erklären, welche Testmethode zu testen versucht. In einigen Fällen, in denen ich mehr Erklärungen benötige, füge ich die Beschreibung hinzu [Test ("Dieser Test bewertet, wie viele Fragen von bestimmten Benutzern beantwortet wurden")].

Eine Sache, um sicherzustellen, dass die Tests lesbarer und schnell verständlich sind.

Answer 5

Ich verwende eine ähnliche Namenskonvention zu dem in Ihrer Frage also method_scenario_expected Ich denke, Sie sollten mehr auf dem „Szenario“ Teil erarbeiten - wenn Sie Parameter sind vorbei - die Leser wissen lassen, was über sie speacial ist .

Denken Sie daran, dass die Benennung Ihrer Tests auf diese Weise mehr "TDD oreinted" ist und keine BDD - BDD - Testnamen über Regeln und "Verhaltensweisen" verfügen sollten.

Wenn Sie der Meinung sind, dass die aktuelle Namenskonvention die Lesbarkeit des Codes nicht berücksichtigt, können Sie experimentieren und herausfinden, was für Sie funktioniert.