空间管理您的位置: 51Testing软件测试网 » Mr.南柯 » 日志

编写综合的单元测试-2

上一篇 / 下一篇 2012-07-04 11:59:49 / 个人分类：杂谈

查看( 220 ) / 评论( 0 ) / 评分( 0 / 0 )

　　测试也有代码味道51Testing软件测试网S C-t-uxj

^P,R/QK v0　　回看第一个测试用例的8个测试，它们都有同样的设置和运算。唯一的不同是我们写的断言。在业界这个被称为一个代码味道。事实上，根据维基百科所列的这里应该有两个代码味道：

FW1]'SrH2w-~0　　● Duplicated code

J"S+B}^M]"S9^a0　　● 重复的代码51Testing软件测试网(C uTp h6u`

YMl&FwW0　　● Excessively long identifiers

　　● 过长的标识符

　　我们可以通过将断言合并到一个测试来轻松地消除这两个代码味道：

!Y#N7cq2N/v0

[TestMethod]
public voidPerson_FirstName_Set()
{
     varperson =newPerson("Adam","Smith");
     vareventAssert =newPropertyChangedEventAssert(person);
     varerrorsChangedAssert =newErrorsChangedEventAssert(person);
     varchangeAssert =newChangeAssert(person);
     person.FirstName ="Bob";
     Assert.AreEqual("Bob", person.FirstName,"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");
     errorsChangedAssert.ExpectNothing("Expected no ErrorsChanged events");
     changeAssert.AssertOnlyChangesAre("FirstName", "FullName", "IsChanged");
}

m^'jO3a{N.w0　　知道什么导致测试失败很重要，因此我们在断言里添加失败的信息提示。

YO%TRZx0　　单元测试和代码重用

g1y4PO5b9Bi)I0　　回看那27个测试用例，我们可以断定设置FirstName为null或者空串应该也需求同样的测试。因此我们可以扩展成：

[TestMethod]
public voidPerson_FirstName_Set_Empty()
{
     Person_FirstName_Set_Invalid(String.Empty);
}
[TestMethod]
public voidPerson_FirstName_Set_Null()
{
     Person_FirstName_Set_Invalid(null);
}
public voidPerson_FirstName_Set_Invalid(stringfirstName)
{
     varperson =newPerson("Adam","Smith");
     vareventAssert =newPropertyChangedEventAssert(person);
     varerrorsChangedAssert =newErrorsChangedEventAssert(person);
     varchangeAssert =newChangeAssert(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("Smith", 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 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.AssertOnlyChangesAre("FirstName","FullName","IsChanged","HasErrors");
}

　　可以发现Person_FirstName_Set和Person_FirstName_Set_Invalid的差异很小，我们可以进一步试着通用化：

　　[TestMethod]

public voidPerson_FirstName_Set_Valid()
{
     Person_FirstName_Set("Bob",false);
}
[TestMethod]
public voidPerson_FirstName_Set_Empty()
{
     Person_FirstName_Set(String.Empty,true);
}
[TestMethod]
public voidPerson_FirstName_Set_Null()
{
     Person_FirstName_Set(null,true);
}
public voidPerson_FirstName_Set(stringfirstName,boolshouldHaveErrors)
{
     varperson =newPerson("Adam","Smith");
     vareventAssert =newPropertyChangedEventAssert(person);
     varerrorsChangedAssert =newErrorsChangedEventAssert(person);
     varchangeAssert =newChangeAssert(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("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.AreEqual(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.ExpectCountEquals(1,"Expected an ErrorsChanged event");
          changeAssert.AssertOnlyChangesAre("FirstName","FullName","IsChanged","HasErrors");
     }
     else
     {
          errorsChangedAssert.ExpectNothing("Expected no ErrorsChanged events");
          changeAssert.AssertOnlyChangesAre("FirstName","FullName","IsChanged");
     }
}

　　在测试代码变得令人迷惑之前，我们可以把它通用化什么程度，这里绝对有个限制。但是一个有意义的测试名称，并给每个断言配一个好的描述可以让你的测试更加容易让人理解。

zTqp1Kq0　　控制变量

!}m;rrPy0　　目前所有的断言都只考虑到了测试用例的输出。他们假设每个Person对象初始状态已知，然后从此出发进行其他操作。但是如果我们想让测试更具科学性，必须确保我们能控制变量。或者换句话说，我们需要保证，一切在掌握之中。

　　请看下面一组断言：51Testing软件测试网;SrIf}

Assert.IsFalse(person.HasErrors,"Test setup failed, HasErrors is not false");
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("Smith", person.LastName,"Test setup failed, LastName is not Smith");

　　由于我们不想在每个测试的开始重复这些断言，我们可以选择把他们移到一个工厂方法中，这样我们可以保证总是拿到一个干净的对象。这个同样适用于重用这些设置去测试其他属性的测试用例。

　　[TestMethod]

0G7ne4Q K2nA|8F051Testing软件测试网*j&nb\&j

public voidPerson_FirstName_Set()
{
varperson = GetAdamSmith();
...

　　表格式的测试

　　之所以走到这一步，是因为“测试方法”的数量跟测试的完善程度没有关系。它们只是组织和执行测试用例一种比较方便的方式。

'XF S!]/w!iU M3~R0　　另一个组织大量测试用例的方法是表格驱动测试法。不能执行单个测试，但是仅用一行代码就可以增加新的测试用例。表格式测试里的表格可以来源于 XML的文件，数据库表，写死在数组里或者只是使用同一个函数用不同的值反复调用。一些框架如MBTest甚至可以让你用属性给出测试用例，但是为了让例子轻便，我们还是坚持保持最低的共同部分。

"@afRV051Testing软件测试网@?O6YeF}z

[TestMethod]
public voidPerson_FullName_Tests()
{
     Person_FullName_Test("Bob","Jones","Bob Jones");
     Person_FullName_Test("Bob ","Jones","Bob Jones");
     Person_FullName_Test(" Bob","Jones","Bob Jones");
     Person_FullName_Test("Bob"," Jones","Bob Jones");
     Person_FullName_Test("Bob","Jones ","Bob Jones");
     Person_FullName_Test(null,"Jones","Jones");
     Person_FullName_Test(string.Empty,"Jones","Jones");
     Person_FullName_Test("      ","Jones","Jones");
     Person_FullName_Test("Bob","","Bob");
     Person_FullName_Test("Bob",null,"Bob");
     Person_FullName_Test("Bob",string.Empty,"Bob");
     Person_FullName_Test("Bob","      ","Bob");
}
private voidPerson_FullName_Test(stringfirstName,stringlastName,stringexpectedFullName)
{
     varperson = GetAdamSmith();
     person.FirstName = firstName;
     person.LastName = lastName;
     Assert.AreEqual(expectedFullName, person.FullName,
          string.Format("Incorrect full name when first name is '{0}' and last name is '{1}'"
          firstName ??"", lastName ??""));
}

z2R-Y7j&c2]0　　在运用这个技巧时，要使用带参数的错误信息，这很重要。如果不加，你会发现在定位哪些参数组合不对时，还得一步一步调试代码。

　　结论

　　在为任何变量编写单元测试时，最好尝试最大化以下几个因素：

　　● 有意义的单位工作量测试覆盖率

　　● 面对变动的代码基线时，保证可维护性

　　● 测试套件的性能

:h:A_b6k9Z5}0　　● 明确说明测试什么以及为什么51Testing软件测试网M%s b`#sMF-U

;Hf2[4?cg\3d0　　鉴于这些因素往往会冲突，谨慎地运用单个用例多重断言可提升上述四个方面，具体做法是： + 减少需要编写的样板代码量 + 减少因API更改而需要更新的样板代码量 + 减少每个断言需要执行的样板代码数量 + 将某一操作的所有断言，用文档记录在同一个地方。

收藏举报

TAG:

查看全部评论