测试代码在实际类的内部写还是外部写的思考

  在我的<<也谈测试驱动开发>>里,提出了对方法级别的测试应该在实际代码的旁边来写的建议。
  不同的博客有不同的看法,我尊重大家的意思,但某些问题似乎不是提得很明确,也可能是因为文中说得不够清楚,这里我来简单地澄清一下。

  在一个类内写实际的代码与测试性的代码,可以采用如下的形式:
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这样的宝贝:)
  既然用了工具,我们就是充分使用,发挥它最大的作用,这样才能提高生产效率。
        关于,代码中的清晰性与耦合度的问题,我下一篇随笔再提及。

posted @ 2005-01-09 18:38  一根神棍研古今  阅读(1138)  评论(3编辑  收藏  举报
Web Counter