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

　　在我的＜＜也谈测试驱动开发＞＞里，提出了对方法级别的测试应该在实际代码的旁边来写的建议。

　　不同的博客有不同的看法，我尊重大家的意思，但某些问题似乎不是提得很明确，也可能是因为文中说得不够清楚，这里我来简单地澄清一下。

　　在一个类内写实际的代码与测试性的代码，可以采用如下的形式：

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这样的宝贝：）

　　既然用了工具，我们就是充分使用，发挥它最大的作用，这样才能提高生产效率。

        关于，代码中的清晰性与耦合度的问题，我下一篇随笔再提及。