ASP.net MVC RTM 测试命名约定答案

【问题标题】：ASP.net MVC RTM Test naming conventionsASP.net MVC RTM 测试命名约定
【发布时间】：2009-09-30 11:15:40
【问题描述】：

我正在开发一个 asp.net mvc 应用程序并编写我的单元测试 BDD 样式。例如。

GetResource_WhenResourceFileExists_ShouldReturnResources()

但是当我为我的控制器编写测试时，我通常有两个同名的方法。一个没有参数用于获取请求，一个用于帖子。有没有人有一个好的命名约定来区分这两者？

我能想到：

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

有什么意见吗？

【问题讨论】：

标签： asp.net-mvc unit-testing tdd testing bdd

【解决方案1】：

我使用以下对我来说效果很好的格式：

[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() {}
}

【讨论】：

【解决方案2】：

我认为这是一个完美的例子，说明为什么单元测试的严格命名约定没有吸引力。

您提出的方案仅在您有两种方法重载时才有效：一种有参数，另一种没有参数。它不会扩展到您有多个具有不同参数的重载的场景。

我个人更喜欢更宽松的命名约定，可以概括为

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

这让我可以灵活地命名我的测试

SutIsPathResolutionCommand
ExecuteWithNullEvaluationContextWillThrow
ExecuteWillAddDefaultClaimsTransformationServiceWhenNoConnectionServiceIsAvailable

我必须承认，无论如何我很少阅读测试的名称。相反，我阅读了它的功能规范（即测试代码）。这个名字对我来说并不重要。

【讨论】：

【解决方案3】：

我不太喜欢的一个选项是给控制器动作不同的名称，然后使用 ActionName 属性重命名它们：

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

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

这实质上是用另一个问题（更难阅读的控制器代码）代替了一个问题（单元测试命名）。不过，您可能会发现这种模式很有吸引力，因为它确实解决了上述问题。

【讨论】：

【解决方案4】：

我使用与您的问题类似的命名约定，即 method_scenario_expected 我认为您应该详细说明“场景”部分-如果您要传递参数-让读者知道它们有什么特别之处。

请记住，以这种方式命名您的测试更加“以 TDD 为导向”并且没有 BDD - BDD 测试名称应该与规则和“行为：”有关。

如果您觉得当前的命名约定无法提高代码的可读性 - 请随意尝试并找到适合您的方法。

【讨论】：

【解决方案5】：

我可能不会回答您的问题，但我想分享一下我的工作。我不遵循特定的命名约定，但我尝试给出解释尝试测试的测试方法的名称。在某些需要更多解释的情况下，我添加了描述 [Test("此测试评估特定用户回答了多少问题")]。

要确保的一件事是测试更具可读性和更容易理解。

【讨论】：