测试代码在实际类的内部写还是外部写的思考
在我的<<也谈测试驱动开发>>里,提出了对方法级别的测试应该在实际代码的旁边来写的建议。
不同的博客有不同的看法,我尊重大家的意思,但某些问题似乎不是提得很明确,也可能是因为文中说得不够清楚,这里我来简单地澄清一下。
在一个类内写实际的代码与测试性的代码,可以采用如下的形式:
using System;
if #DEBUG
using NUnit.Framework;
endif
if #DEBUG
[TestFixture]
endif
public class Sample
{
public Sample();
#region 将测试代码写在这个块里面
if #DEBUG
[Test]
public void 测试用例
{
Sample sample = new Sample();
Assert.IsTrue(sample.sum(1,1)==2);
Assert.IsTrue(sample.sum(1,2)==3);
Assert.IsTrue(sample.sum(0,9)==9);
}
public int 求和(int a,int b)
{
return sum(a,b)
}
#endif
#endregion
private int sum(int a,int b)
{
return a+b;
}
}
这是对sum方法进行测试的一个例子,上面用彩色标记出来的方法,是在预编译指令中写的,在不破坏sum函数的合理封装性的前提之下,仍然能够对sum函数进行测试,同时这样也避免了许多问题的出现。
测试应该只关注输入与输入与输出,采用白盒测试,更多的情况是为了寻找并验证代码的逻辑,用于寻找造成bug之所在的代码(既然要敏捷,就不要受局限)。
Java中没有把它们写在一起,更多的原因是,Java的编辑器中,很少有Visual Studio.net2003这样的好东本,并提供#region...#endregion这样的宝贝:)
既然用了工具,我们就是充分使用,发挥它最大的作用,这样才能提高生产效率。
关于,代码中的清晰性与耦合度的问题,我下一篇随笔再提及。