引用：http://www.cnblogs.com/William_Fire/articles/102241.html

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

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