每个函数/方法应该写多少个单元测试？

Question

您是否为每个函数/方法编写一个测试，在测试中使用多个检查，还是为每个检查测试？

Answer 1

一个测试，每个实例：

@Test 
public void userCannotVoteDownWhenScoreIsLessThanOneHundred() { 
... 
} 

都只有一个断言和使用好名字测试失败时给了我一个更好的报告。他们向我尖叫：“你打破了这个规则！”。

Answer 2

每个检查的测试用例。它更细化。它使得查看特定测试用例失败的情况变得更加容易。

Answer 3

BDD（行为驱动开发）

虽然我还在学习，它基本上TDD组织/重点围绕如何你的软件实际使用...这将不是如何开发/内置。

Wikipedia General Info

每个测试方法我会建议您尝试左右逢源BTW至于是否做多的断言。有时你会看到一种策略将你留在一个绑定中，并且开始有意义为什么你通常使用每个方法只使用一个断言。

Answer 4

我会建议每个检查的测试用例。 你保持原子越多，结果就越好！

在单个测试中保留多个检查将帮助您生成需要更正多少功能的报告。

保持原子测试案例会告诉你整体质量！

Answer 5

每个检查一个测试用例。如果您适当地命名该方法，则可以在这些测试之一导致回归失败时为问题提供有价值的提示。

Answer 6

我有一个测试能力功能提供。然而，每个测试可能有几个断言。 测试用例的名称表示正在测试的功能。

一般来说，对于一个功能，我有几个“晴天”测试和一个或几个“下雨天”的情况，这取决于它的复杂性。

Answer 7

我为每个方法编写至少一个测试，并且如果方法需要一些不同的setUp来测试好的情况和不好的情况，那么这个时间就会多一些。

但你应该从不在一个单元测试中测试多个方法。它会减少工作量和错误修复您的测试，以防API更改。每张支票和超级描述性的名称

Answer 8

我试图分离出数据库测试和业务逻辑测试（使用其他人推荐的BDD），首先运行数据库测试，确保数据库处于良好状态，然后让您的应用程序使用它。

有一个很好的podcast show with Andy Leonard on what it involves and how to do it，如果你想要更多的信息，我写了一个blog post on the subject（无耻插头; O）

Answer 9

在每张支票一般一个测试用例。当测试按特定函数分组时，它会使重构（例如移除或分割）功能变得更加困难，因为测试还需要进行大量更改。针对你想要从课堂中学到的每种行为类型编写测试要好得多。有时候在测试特定的行为时，每个测试用例都有多个检查是有意义的。然而，随着考试变得越来越复杂，班级中的某些内容发生变化时，这些考试变得更加困难。

Answer 10

在Java/Eclipse/JUnit中，我在同一棵树上使用了两个源目录（src和test）。 如果我有一个的src/COM/myCompany的/不管/ TestMePlease与价值的测试方法（例如deleteAll（名单<？>东西）抛出MyException）我创建了一个测试/ COM/myCompany的/不管/ TestMePleaseTest与方法来测试不同的使用情况/场景：

@Test 
public void deleteAllWithNullInput() { ... } 

@Test(expect="MyException.class") // not sure about actual syntax here :-P 
public void deleteAllWithEmptyInput() { ... } 

@Test 
public void deleteAllWithSingleLineInput() { ... } 

@Test 
public void deleteAllWithMultipleLinesInput() { ... } 

有不同的检查更容易处理我。尽管如此，因为每个测试都应该是一致的，如果我希望我的初始数据集保持不变，例如，我有时会创建东西并在相同的检查中将其删除，以确保其他每个测试都能找到原始数据集：

@Test 
public void insertAndDelete() { 
    assertTrue(/*stuff does not exist yet*/); 
    createStuff(); 
    assertTrue(/*stuff does exist now*/); 
    deleteStuff(); 
    assertTrue(/*stuff does not exist anymore*/); 
} 

不知道是否有更聪明的方式来做到这一点，告诉你真相......

Answer 11

我喜欢每张支票测试的方法，并有meaningfull名测试方法。例如：

testAddUser_shouldThrowIllegalArgumentExceptionWhenUserIsNull

Answer 12

我认为单断言的规则是有点过于严格。在我的单元测试中，我尝试遵循单个断言规则 - 您可以在一个测试方法中使用多个断言，只要您一个接一个地执行检查（您不会更改状态在断言之间被测试的类）。

因此，在Python，我相信这样的测试是正确：

def testGetCountReturnsCountAndEnd(self): 
    count, endReached = self.handler.getCount() 
    self.assertEqual(count, 0) 
    self.assertTrue(endReached) 

，但这个应该是分裂成两种测试方法：

def testGetCountReturnsOneAfterPut(self): 
    self.assertEqual(self.handler.getCount(), 0) 
    self.handler.put('foo') 
    self.assertEqual(self.handler.getCount(), 1) 

当然，在长时间使用的断言组中，我喜欢创建自定义断言方法 - 这些对比较复杂对象特别有用。