单元测试：敏捷并知道要测试什么？根据需求测试？

之前，我用来实现单元测试只是为了测试的方法是否工作。但在其他地方看完之后，它出现时的方法失败，我应该测试。单元测试：敏捷并知道要测试什么？根据需求测试？

例如，一个方法应该抛出一个Exception传递一个字符串。

哪里都来自这些要求？

我正在一个敏捷团队工作，因此我们获得了包含应用程序功能的基本要求的用户故事。这些基本要求包括非常简单要求（即密码应是最多8个字符的长度）。

然后我根据需求从这个用户故事创建任务。

因此，在测试时......究竟应该测试什么？

我想我应该测试方法（它是作为用户故事一部分的一个任务的一部分）的功能应该是这样，但我也应该测试它应该失败吗？

例如，当需求最多为8个字符时，将12个字符传递给方法的参数（密码）。我必须为此包含一个测试用例吗？

有没有人知道一个很好的资源或链接，解释更多关于这个问题？

我假设没有要求我只能测试方法是否成功，而不是失败，因为我不知道什么时候应该失败，因为没有要求？

任何人可以提供帮助将是非常有益的。

来源

2012-07-22 Martin

您有没有想过[角落或边缘情况]（http://en.wikipedia.org/wiki/Corner_case）您的故事要求？ – Akim 2012-07-22 17:53:37

我认为你对阅读失败太多了。它的意思是你写的代码（除了存根，将总是返回空像一个无效的值）之前编写测试。这样你就知道你有代码在失败时写入。然后，你编写代码并再次测试。测试现在应该通过。测试驱动的开发应该总是像这样工作。

来源

2012-07-22 16:54:43 Surfbutler

+1。更好的是，在你编写代码让它通过之前，你的测试应该会失败_带有一个明确的，有意义的错误消息。 – DNA 2012-07-22 21:43:21

虽然你当然不能测试每的可能性，你应该在至少测试代码中考虑的可能性。

：

你的榜样，在传递给方法的字符串不得超过8个字符（这是一个密码可怕要求的方式），该方法可能会是这个样子

所以

public bool IsPasswordCorrect(string password) 
{ 
    if (password.Length > 8) 
     throw new ArgumentException("Password must not be greater than 8 characters."); 

    return password == SomeKnownPassword; 
}

目标应该是100％的代码覆盖率。这意味着每行代码实际上应该有至少一个相应的测试。因此，如果只考是针对“快乐路径”（字符串，其不大于8个字符），然后throw线从来没有测试。

该行代码是为响应需求而存在的，因此需要测试该需求。在这种情况下，你有几个测试：

[TestMethod] 
public void MatchingPasswordsShouldBeAllowed() 
{ 
    // set the known password 
    // set the passed password 
    // call the method 
    // assert that the method returned true 
} 

[TestMethod] 
public void NonMatchingPasswordsShouldNotBeAllowed() 
{ 
    // set the known password 
    // set the passed password to something else 
    // call the method 
    // assert that the method returned false 
} 

[TestMethod] 
[ExpectedException(typeof(ArgumentException))] 
public void PasswordsShouldNotBeGreaterThanEightCharacters() 
{ 
    // set the known password 
    // set the passed password to something too long 
    // call the method 
    // assert that an exception was thrown 
}

公告的测试方法的名称。他们听起来像要求。这个想法是，所述的要求应该分解成实际的规格。业务要求是：

密码应不超过8个字符

但那里有隐含的要求是什么？要求如：

提供的密码与已知密码匹配应导致身份验证。

提供的密码与已知密码不匹配不应导致认证。

毕竟，该方法是做所有这些事情。如果该方法正在做某件事，那么应该测试一些东西。最终，代码所做的一切应该至少有一个映射到需求的相应测试。

事实上，如果测试写得不错，他们开始成为的要求。这很好，因为这意味着有问题的知识（需求）可以保存在一个地方（测试），而不是多个不同的地方（测试，代码，文档，白板等）。

如果有一行代码没有被测试执行，那么为什么那行代码在那里？如果没有测试，那就没有要求了。如果没有要求，请将其移除。

来源

2012-07-22 17:14:20 David

开始快乐路径测试。你的快乐之路应该基于需求的用例。

当您覆盖所有的幸福路径，继续边界测试。所以，当它应该是8个字符的密码，然后做7,8,9个字符的测试，并覆盖这个场景。

后您覆盖所有的快乐路径和边界测试，问自己我怎么能写失败的测试？如果你能弄清楚，然后写下来。如果它是应该提出的例外，然后覆盖它。考虑到这一点，你可以很容易地弄清楚应该测试什么，什么是不必要的。

来源

2012-07-22 20:01:02 Adronius

单元测试：敏捷并知道要测试什么？根据需求测试？

回答

相关问题