在测试代码变得令人迷惑之前，我们可以把它通用化什么程度，这里有个限制。但是一个有意义的测试名称，并给每个断言配一个好的描述可以让你的测试更加容易让人理解。
   
    控制变量
   
    目前所有的断言都只考虑到了测试用例的输出。他们假设每个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更改而需要更新的样板代码量 + 减少每个断言需要执行的样板代码数量 + 将某一操作的所有断言，用文档记录在同一个地