如何编写综合的单元测试方案.docx

1、如何编写综合的单元测试方案每个用例编写一到二个断言是单元测试最佳实践的常见内容.那些这么认为的是极少和只展示一个单元测试的人。因此如果你采纳他们的建议，为一个很小的运算你都需要大量的单元测试去保证质量。这篇文章意图通过例子展示，一个测试用例多个断言是有必要和有价值的。 Person这个对象在数据绑定场景中经常出现，我们来看下。 测试FirstName 第一个来测试FirstName这个属性的设置，开始如下： TestMethod 123456 java keywordpublic void Person_FirstName_Set() varperson = new Person(Adam,

2、Smith); person.FirstName = Bob; Assert.AreEqual(Bob, person.FirstName); 接下来我们来测试FirstName的改变通知。 TestMethod 1234567 public void Person_FirstName_Set_PropertyChanged() var person = new Person(Adam, Smith); var eventAssert = new Granite.Testing.PropertyChangedEventAssert(person); person.FirstName = Bob

3、; eventAssert.Expect(FirstName); 当我们执行这个测试时，会得到一个失败提示信息“期望的属性名FirstName，但接收到的是IsChanged”。显然，设置FirstName的属性触发了“IsChanged”标记，我们需要把它考虑在内。因此我们把它加入： TestMethod 12345678 public void Person_FirstName_Set_PropertyChanged() var person = new Person(Adam, Smith); var eventAssert = new Granite.Testing.PropertyC

4、hangedEventAssert(person); person.FirstName = Bob; eventAssert.SkipEvent(); /this was IsChanged eventAssert.Expect(FirstName); 鉴于以上两个测试，我们考虑当FirstName被修改时还有其他什么属性会改变。查看API，IsChanged和FullName属性会变化。 TestMethod 123456 public void Person_FullName_Changed_By_Setting_FirstName() var person = new Person(Ad

5、am, Smith); person.FirstName = Bob; Assert.AreEqual(Bob Smith, person.FullName); TestMethod123456 public void Person_IsChanged_Changed_By_Setting_FirstName() var person = new Person(Adam, Smith); person.FirstName = Bob; Assert.IsTrue(person.IsChanged); 当然，如果这些属性改变了，我们需要获取到属性改变通知： TestMethod 1234567

6、public void Person_IsChanged_Property_Change_Notification_By_Setting_FirstName() var person = new Person(Adam, Smith); var eventAssert = new PropertyChangedEventAssert(person); person.FirstName = Bob; eventAssert.Expect(IsChanged); TestMethod 123456789 public void Person_FullName_Property_Change_Not

7、ification_By_Setting_FirstName() var person = new Person(Adam, Smith); var eventAssert = new PropertyChangedEventAssert(person); person.FirstName = Bob; eventAssert.SkipEvent(); /this was IsChanged eventAssert.SkipEvent(); /this was FirstName eventAssert.Expect(FullName); 接下来两个测试针对HasErrors这个属性和Erro

8、rsChanged事件。 TestMethod 123456 public void Person_FirstName_Set_HasErrorsIsFalse() var person = new Person(Adam, Smith); person.FirstName = Bob; Assert.IsFalse(person.HasErrors); TestMethod 1234567 public void Person_FirstName_Set_ErrorsChanged_Did_Not_Fire() var person = new Person(Adam, Smith); va

9、r errorsChangedAssert = new ErrorsChangedEventAssert(person); person.FirstName = Bob; errorsChangedAssert.ExpectNothing(); 目前我们有8个测试了，这意味着当我们修改FirstName的属性值，我们要考虑会发生改变的每件事。但是这不算完。我们还需要确保没有别的会被意外改变。理论上说，这意味着更多的断言和相当数量的测试，但是，接下来我们采用取巧的方法，用ChangeAssert方法来替代HasErrors测试。 TestMethod 1234567 public void Pe

10、rson_FirstName_Set_Nothing_Unexpected_Changed() var person = new Person(Adam, Smith); var changeAssert = new ChangeAssert(person); person.FirstName = Bob; changeAssert.AssertOnlyChangesAre(FirstName, FullName, IsChanged); ChangeAssert简单地通过映射获取对象的状态，因此，稍后你可以断言到除了你指出的几个具体属性其他的没变。 恭喜，你完成了你的第一个测试用例。完成一个

11、，还有很多很多等着。 为什么说是“一个”测试用例? 那8个测试只是完成了覆盖FirstName属性从“Adam”修改成“Bob”这一个场景，在其他的值没有在错误状态、LastName不为null或空的情况下。让我们看看测试用例的完整清单： 将FirstName值设置为“Adam” 将FirstName值设置为null 将FirstName 设为空串 在LastName值为null的情况下，执行case1-3 在LastName 为空串的情况下，执行case1-3 在FirstName值以null开头的情况下，执行case1-5 在FirstName值以空串开头的情况下，执行case1-5 目前

12、我们看到了27个不同的场景。如果每个场景需要8个不同测试，仅仅为这一个属性，我们需要执行至多216个测试。根据这种思路，这是相当琐碎的一段代码。因此我们该怎么做呢? 测试也有代码味道 回看第一个测试用例的8个测试，它们都有同样的设置和运算。唯一的不同是我们写的断言。在业界这个被称为一个代码味道。事实上，根据维基百科所列的这里应该有两个代码味道： Duplicated code 重复的代码 Excessively long identifiers 过长的标识符 我们可以通过将断言合并到一个测试来轻松地消除这两个代码味道： TestMethod 12345678910111213141516 pu

13、blic void Person_FirstName_Set() var person = new Person(Adam, Smith); var eventAssert = new PropertyChangedEventAssert(person); var errorsChangedAssert = new ErrorsChangedEventAssert(person); var changeAssert = new ChangeAssert(person); person.FirstName = Bob; Assert.AreEqual(Bob, person.FirstName,

14、 FirstName setter failed); Assert.AreEqual(Bob Smith, person.FullName, FullName not updated with FirstName changed); Assert.IsTrue(person.IsChanged, IsChanged flag was not set when FirstName changed); eventAssert.Expect(IsChanged); eventAssert.Expect(FirstName); eventAssert.Expect(FullName); errorsC

15、hangedAssert.ExpectNothing(Expected no ErrorsChanged events); changeAssert.AssertOnlyChangesAre(FirstName, FullName, IsChanged); 知道什么导致测试失败很重要，因此我们在断言里添加失败的信息提示。 单元测试和代码重用 回看那27个测试用例，我们可以断定设置FirstName为null或者空串应该也需求同样的测试。因此我们可以扩展成： TestMethod 1234 public void Person_FirstName_Set_Empty() Person_First

16、Name_Set_Invalid(String.Empty); TestMethod 123456789101112131415161718192021222324 public void Person_FirstName_Set_Null() Person_FirstName_Set_Invalid(null); public void Person_FirstName_Set_Invalid(string firstName) var person = new Person(Adam, Smith); var eventAssert = new PropertyChangedEventAs

17、sert(person); var errorsChangedAssert = new ErrorsChangedEventAssert(person); var changeAssert = new ChangeAssert(person); Assert.IsFalse(person.IsChanged, Test setup failed, IsChanged is not false); Assert.AreEqual(Adam, person.FirstName, Test setup failed, FirstName is not Adam); Assert.AreEqual(S

18、mith, person.LastName, Test setup failed, LastName is not Smith); person.FirstName = firstName; Assert.AreEqual(firstName , person.FirstName, FirstName setter failed); Assert.AreEqual(Smith, person.FullName, FullName not updated with FirstName changed); Assert.IsTrue(person.IsChanged, IsChanged flag

19、 was not set when FirstName changed); eventAssert.Expect(IsChanged); eventAssert.Expect(FirstName); eventAssert.Expect(FullName); Assert.IsTrue(person.HasErrors, HasErrors should have remained false); errorsChangedAssert.ExpectCountEquals(1, Expected an ErrorsChanged event); changeAssert.AssertOnlyC

20、hangesAre(FirstName, FullName, IsChanged, HasErrors); 可以发现Person_FirstName_Set和Person_FirstName_Set_Invalid的差异很小，我们可以进一步试着通用化： TestMethod 1234 public void Person_FirstName_Set_Valid() Person_FirstName_Set(Bob, false); TestMethod 1234 public void Person_FirstName_Set_Empty() Person_FirstName_Set(Stri

21、ng.Empty, true); TestMethod 1234567891011121314151617181920212223242526272829303132 public void Person_FirstName_Set_Null() Person_FirstName_Set(null, true); public void Person_FirstName_Set(string firstName, bool shouldHaveErrors) var person = new Person(Adam, Smith); var eventAssert = new Property

22、ChangedEventAssert(person); var errorsChangedAssert = new ErrorsChangedEventAssert(person); var changeAssert = new ChangeAssert(person); Assert.IsFalse(person.IsChanged, Test setup failed, IsChanged is not false); Assert.AreEqual(Adam, person.FirstName, Test setup failed, FirstName is not Adam); Ass

23、ert.AreEqual(Smith, person.LastName, Test setup failed, LastName is not Smith); person.FirstName = firstName; Assert.AreEqual(firstName, person.FirstName, FirstName setter failed); Assert.AreEqual(firstName + Smith).Trim(), person.FullName, FullName not updated with FirstName changed); Assert.AreEqu

24、al(true, person.IsChanged, IsChanged flag was not set when FirstName changed); eventAssert.Expect(IsChanged); eventAssert.Expect(FirstName); eventAssert.Expect(FullName); if (shouldHaveErrors) Assert.IsTrue(person.HasErrors, HasErrors should have remained false); errorsChangedAssert.ExpectCountEqual

25、s(1, Expected an ErrorsChanged event); changeAssert.AssertOnlyChangesAre(FirstName, FullName, IsChanged, HasErrors); else errorsChangedAssert.ExpectNothing(Expected no ErrorsChanged events); changeAssert.AssertOnlyChangesAre(FirstName, FullName, IsChanged); 在测试代码变得令人迷惑之前，我们可以把它通用化什么程度，这里绝对有个限制。但是一个有

26、意义的测试名称，并给每个断言配一个好的描述可以让你的测试更加容易让人理解。 控制变量 目前所有的断言都只考虑到了测试用例的输出。他们假设每个Person对象初始状态已知，然后从此出发进行其他操作。但是如果我们想让测试更具科学性，必须确保我们能控制变量。或者换句话说，我们需要保证，一切在掌握之中。 请看下面一组断言： 1234 Assert.IsFalse(person.HasErrors, Test setup failed, HasErrors is not false); Assert.IsFalse(person.IsChanged, Test setup failed, IsChang

27、ed is not false); Assert.AreEqual(Adam, person.FirstName, Test setup failed, FirstName is not Adam); Assert.AreEqual(Smith, person.LastName, Test setup failed, LastName is not Smith); 由于我们不想在每个测试的开始重复这些断言，我们可以选择把他们移到一个工厂方法中，这样我们可以保证总是拿到一个干净的对象。这个同样适用于重用这些设置去测试其他属性的测试用例。 TestMethod 1234 public void P

28、erson_FirstName_Set() var person = GetAdamSmith(); . 表格式的测试 之所以走到这一步，是因为“测试方法”的数量跟测试的完善程度没有关系。它们只是组织和执行测试用例一种比较方便的方式。 另一个组织大量测试用例的方法是表格驱动测试法。不能执行单个测试，但是仅用一行代码就可以增加新的测试用例。表格式测试里的表格可以来源于XML的文件，数据库表，写死在数组里或者只是使用同一个函数用不同的值反复调用。一些框架如MBTest甚至可以让你用属性给出测试用例，但是为了让例子轻便，我们还是坚持保持最低的共同部分。 TestMethod 123456789101112131415161718192021222324 public void Person_FullName_Tests() Person_FullName_Test(Bob, Jones, Bob Jones); Person_FullName_Test(Bob , Jones, Bob Jones); Person_FullName_Test( Bob, Jones, Bob J