编写综合的单元测试
作者:网络转载 发布时间:[ 2012/7/3 11:15:57 ] 推荐标签:
在测试代码变得令人迷惑之前,我们可以把它通用化什么程度,这里有个限制。但是一个有意义的测试名称,并给每个断言配一个好的描述可以让你的测试更加容易让人理解。
控制变量
目前所有的断言都只考虑到了测试用例的输出。他们假设每个Person对象初始状态已知,然后从此出发进行其他操作。但是如果我们想让测试更具科学性,必须确保我们能控制变量。或者换句话说,我们需要保证,一切在掌握之中。
请看下面一组断言:
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]
public void Person_FirstName_Set()
{
var person = GetAdamSmith();
...
表格式的测试
之所以走到这一步,是因为“测试方法”的数量跟测试的完善程度没有关系。它们只是组织和执行测试用例一种比较方便的方式。
另一个组织大量测试用例的方法是表格驱动测试法。不能执行单个测试,但是仅用一行代码可以增加新的测试用例。表格式测试里的表格可以来源于XML的文件,数据库表,写死在数组里或者只是使用同一个函数用不同的值反复调用。一些框架如MBTest甚至可以让你用属性给出测试用例,但是为了让例子轻便,我们还是坚持保持低的共同部分。
[TestMethod]
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 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 void Person_FullName_Test(string firstName, string lastName, string expectedFullName)
{
var person = 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 ?? ""));
}
在运用这个技巧时,要使用带参数的错误信息,这很重要。如果不加,你会发现在定位哪些参数组合不对时,还得一步一步调试代码。
结论
在为任何变量编写单元测试时,好尝试大化以下几个因素:
● 有意义的单位工作量测试覆盖率
● 面对变动的代码基线时,保证可维护性
● 测试套件的性能
● 明确说明测试什么以及为什么
鉴于这些因素往往会冲突,谨慎地运用单个用例多重断言可提升上述四个方面,具体做法是: + 减少需要编写的样板代码量 + 减少因API更改而需要更新的样板代码量 + 减少每个断言需要执行的样板代码数量 + 将某一操作的所有断言,用文档记录在同一个地方。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11