.NET单元测试的艺术-3.测试代码

开篇：上一篇我们学习单元测试和核心技术：存根、模拟对象和隔离框架，它们是我们进行高质量单元测试的技术基础。本篇会集中在管理和组织单元测试的技术，以及如何确保在真实项目中进行高质量的单元测试。

系列目录：

1.入门

2.核心技术

3.测试代码

一、测试层次和组织

1.1 测试项目的两种目录结构

　　（1）集成测试和单元测试在同一个项目里，但放在不同的目录和命名空间里。基础类放在单独的文件夹里。

　　（2）集成测试和单元测试位于不同的项目中，有不同的命名空间。

实践中推荐使用第二种目录结构，因为如果我们不把这两种测试分开，人们可能就不会经常地运行这些测试。既然测试都写好了，为什么人们不愿意按照需要运行它们呢？一个原因是：开发人员有可能懒得运行测试，或者没有实践运行测试。

1.2 构建绿色安全区

　　将集成测试和单元测试分开放置，其实就给团队的开发人员构建了绿色安全区，这个区只包含单元测试。

　　因为集成测试的本质决定了它运行时间较长，开发人员很有可能每天运行多次单元测试，较少运行集成测试。

单元测试全部通过至少可以使开发人员对代码质量比较有信心，专注于提高编码效率。而且我们应该将测试自动化，编写每日构建脚本，并借助持续集成工具帮助我们自动执行这些脚本。

1.3 将测试类映射到被测试代码

　　（1）将测试映射到项目

　　创建一个测试项目，用被测试项目的名字加上后缀.UnitTests来命名。

　　例如：Manulife.MyLibrary → Manulife.MyLibrary.UnitTests 和 Manulife.MyLibrary.IntegrationTests，这种方法看起来简单直观，开发人员能够从项目名称找到对应的所有测试。

　　（2）将测试映射到类

　　① 每个被测试类或者被测试工作单元对应一个测试类：LogAnalyzer → LogAnalyzer.UnitTests

　　② 每个功能对应一个测试类：有一个LoginManager类，测试方法为ChangePassword（这个方法测试用例特别多，需要单独放在一个测试类里边） → 创建两个类 LoginManagerTests 和 LoginManagerTests-ChangePassword，前者只包含对ChangePassword方法的测试，后者包含该类其他所有测试。

　　（3）将测试映射到具体的工作单元入口

　　测试方法的命名应该有意义，这样人们可以很容易地找到所有相关的测试方法。

　　这里，回归一下第一篇中提到的测试方法名称的规范，一般包含三个部分：[UnitOfWorkName]_[ScenarioUnderTest]_[ExpectedBehavior]

• • UnitOfWorkName　　被测试的方法、一组方法或者一组类
  • Scenario　　测试进行的假设条件，例如“登入失败”，“无效用户”或“密码正确”等
  • ExpectedBehavior　　在测试场景指定的条件下，你对被测试方法行为的预期　　

　　示例：IsValidFileName_BadExtension_ReturnsFalse，IsValidFileName_EmptyName_Throws 等

1.4 注入横切关注点

　　当需要处理类似时间管理、异常或日志的横切关注点时，使用它们的地方会非常多，如果把它们实现成可注入的，产生的代码会很容易测试，但却很难阅读和理解。这里我们来看一个例子，假设应用程序使用当前时间进行写日志，相关代码如下：

    public static class TimeLogger
    {
        public static string CreateMessage(string info)
        {
            return DateTime.Now.ToShortDateString() + " " + info;
        }
    }

　　为了使这段代码容易测试，如果使用之前的依赖注入技术，那么我们需要创建一个ITimeProvider接口，还必须在每个用到DateTime的地方使用到这个接口。这样做非常耗时，实际上，还有更直接的方法解决这个问题。

　　Step1.创建一个名为SystemTime的定制类，在所有的产品代码里边使用这个定制类，而非标准的内建类DateTime。

    public class SystemTime
    {
        private static DateTime _date;

        public static void Set(DateTime custom)
        {
            _date = custom;
        }

        public static void Reset()
        {
            _date = DateTime.MinValue;
        }

        public static DateTime Now
        {
            get
            {
                // 如果设置了时间，SystemTime就返回假时间，否则返回真时间
                if (_date != DateTime.MinValue)
                {
                    return _date;
                }
                return DateTime.Now;
            }
        }
    }

　　阅读这段代码，其中有一个小技巧：SystemTime类提供一个特殊方法Set，它会修改系统中的当前时间，也就是说，每个使用这个SystemTime类的人看到的都是你指定的日期和时间。有了这样的代码，每个使用这个SystemTime类的人看到的都会是你指定的日期和时间。

　　Step2.在测试项目中使用SystemTime进行测试。

    [TestFixture]
    public class TimeLoggerTests
    {
        [Test]
        public void SettingSystemTime_Always_ChangesTime()
        {
            SystemTime.Set(new DateTime(2000, 1, 1));
            string output = TimeLogger.CreateMessage("a");

            StringAssert.Contains("2000/1/1", output);
        }

        /// <summary>
        /// 在每个测试结束时重置日期
        /// </summary>
        [TearDown]
        public void AfterEachTest()
        {
            SystemTime.Reset();
        }
    }

　　在测试中，我们首先假定设置一个日期，然后进行断言。并且借助TearDown方法，确保当前测试不会改变其他测试的值。

Note ： 这样做的好处就在于不用注入一大堆接口，我们所付出的代价仅仅在于在测试类中加入一个简单的[TearDown]方法，确保当前测试不会改变其他测试的值。

1.5 使用继承使测试代码可重用

　　推荐大家在测试代码中使用继承机制，通过实现基类，可以较好地展现面向对象的魔力。在实践中，一般有三种模式会被使用到：

　　（1）抽象测试基础结构类模式

    /// <summary>
    /// 测试类集成模式
    /// </summary>
    [TestFixture]
    public class BaseTestsClass
    {
        /// <summary>
        /// 重构为通用可读的工具方法，由派生类使用
        /// </summary>
        /// <returns>FakeLogger</returns>
        public ILogger FakeTheLogger()
        {
            LoggingFacility.Logger = Substitute.For<ILogger>();
            return LoggingFacility.Logger;
        }

        [TearDown]
        public void ClearLogger()
        {
            // 测试之间要重置静态资源
            LoggingFacility.Logger = null;
        }
    }

    [TestFixture]
    public class LogAnalyzerTests : BaseTestsClass
    {
        [Test]
        public void Analyze_EmptyFile_ThrowsException()
        {
            // 调用基类的辅助方法
            FakeTheLogger();

            LogAnalyzer analyzer = new LogAnalyzer();
            analyzer.Analyze("myemptyfile.txt");

            // 测试方法的其余部分
        }
    }

　　使用此模式要注意继承最好不要超过一层，如果继承层数过多，不仅可读性急剧下降，编译也很容易出错。

　　（2）测试类类模板模式

    /// <summary>
    /// 测试模板类模式
    /// </summary>
    [TestFixture]
    public abstract class TemplateStringParserTests
    {
        [Test]
        public abstract void TestGetStringVersionFromHeader_SingleDigit_Found();
        [Test]
        public abstract void TestGetStringVersionFromHeader_WithMinorVersion_Found();
        [Test]
        public abstract void TestGetStringVersionFromHeader_WithRevision_Found();
    }

    [TestFixture]
    public class XMLStrignParserTests : TemplateStringParserTests
    {
        protected IStringParser GetParser(string input)
        {
            return new XMLStringParser(input);
        }

        [Test]
        public override void TestGetStringVersionFromHeader_SingleDigit_Found()
        {
            IStringParser parser = GetParser("<Header>1</Header>");

            string versionFromHeader = parser.GetTextVersionFromHeader();
            Assert.AreEqual("1", versionFromHeader);
        }

        [Test]
        public override void TestGetStringVersionFromHeader_WithMinorVersion_Found()
        {
            IStringParser parser = GetParser("<Header>1.1</Header>");

            string versionFromHeader = parser.GetTextVersionFromHeader();
            Assert.AreEqual("1.1", versionFromHeader);
        }

        [Test]
        public override void TestGetStringVersionFromHeader_WithRevision_Found()
        {
            IStringParser parser = GetParser("<Header>1.1.1</Header>");

            string versionFromHeader = parser.GetTextVersionFromHeader();
            Assert.AreEqual("1.1", versionFromHeader);
        }
    }

　　使用此模式可以确保开发者不会遗忘重要的测试，基类包含了抽象的测试方法，派生类必须实现这些抽象方法。

　　（3）抽象测试驱动类模式

    /// <summary>
    /// 抽象“填空”测试驱动类模式
    /// </summary>
    public abstract class FillInTheBlankStringParserTests
    {
        // 返回接口的抽象方法
        protected abstract IStringParser GetParser(string input);
        // 抽象输入方法（属性），为派生类提供特定格式的数据
        protected abstract string HeaderVersion_SingleDigit { get; }
        protected abstract string HeaderVersion_WithMinorVersion { get; }
        protected abstract string HeaderVersion_WithRevision { get; }
        // 如果需要，预先为派生类定义预期的输出
        public const string EXPECTED_SINGLE_DIGIT = "1";
        public const string EXPECTED_WITH_MINORVERSION = "1.1";
        public const string EXPECTED_WITH_REVISION = "1.1.1";

        [Test]
        public void TestGetStringVersionFromHeader_SingleDigit_Found()
        {
            string input = HeaderVersion_SingleDigit;
            IStringParser parser = GetParser(input);

            string versionFromHeader = parser.GetTextVersionFromHeader();
            Assert.AreEqual(EXPECTED_SINGLE_DIGIT, versionFromHeader);
        }

        [Test]
        public void TestGetStringVersionFromHeader_WithMinorVersion_Found()
        {
            string input = HeaderVersion_WithMinorVersion;
            IStringParser parser = GetParser(input);

            string versionFromHeader = parser.GetTextVersionFromHeader();
            Assert.AreEqual(EXPECTED_WITH_MINORVERSION, versionFromHeader);
        }

        [Test]
        public void TestGetStringVersionFromHeader_WithRevision_Found()
        {
            string input = HeaderVersion_WithRevision;
            IStringParser parser = GetParser(input);

            string versionFromHeader = parser.GetTextVersionFromHeader();
            Assert.AreEqual(EXPECTED_WITH_REVISION, versionFromHeader);
        }
    }

    public class DBLogStringParserTests : GenericParserTests<DBLogStringParser>
    {
        protected override string GetInputHeaderSingleDigit()
        {
            return "Header;1";
        }

        protected override string GetInputHeaderWithMinorVersion()
        {
            return "Header;1.1";
        }

        protected override string GetInputHeaderWithRevision()
        {
            return "Header;1.1.1";
        }
    }

　　此模式在基类中实现测试方法，并提供派生类可以实现的抽象方法钩子。当然，只是大部分的测试代码在基类中，派生类也可以加入自己的特殊测试。

　　此模式的要点在于：你不是具体地测试一个类，而是测试产品代码中的一个接口或者基类。

　　当然，在.NET中我们也可以通过泛型来实现此模式，例如下面的代码：

    public abstract class GenericParserTests<T> where T : IStringParser // 01.定义参数的泛型约束
    {
        protected abstract string GetInputHeaderSingleDigit();
        protected abstract string GetInputHeaderWithMinorVersion();
        protected abstract string GetInputHeaderWithRevision();

        // 02.返回泛型变量而非接口
        protected T GetParser(string input)
        {
            // 03.返回泛型
            return (T)Activator.CreateInstance(typeof(T), input);
        }

        [Test]
        public void TestGetStringVersionFromHeader_SingleDigit_Found()
        {
            string input = GetInputHeaderSingleDigit();
            T parser = GetParser(input);

            bool result = parser.HasCorrectHeader();
            Assert.AreEqual(false, result);
        }

        [Test]
        public void TestGetStringVersionFromHeader_WithMinorVersion_Found()
        {
            string input = GetInputHeaderWithMinorVersion();
            T parser = GetParser(input);

            bool result = parser.HasCorrectHeader();
            Assert.AreEqual(false, result);
        }

        [Test]
        public void TestGetStringVersionFromHeader_WithRevision_Found()
        {
            string input = GetInputHeaderWithRevision();
            T parser = GetParser(input);

            bool result = parser.HasCorrectHeader();
            Assert.AreEqual(false, result);
        }
    }

    public class DBLogStringParserTests : GenericParserTests<DBLogStringParser>
    {
        protected override string GetInputHeaderSingleDigit()
        {
            return "Header;1";
        }

        protected override string GetInputHeaderWithMinorVersion()
        {
            return "Header;1.1";
        }

        protected override string GetInputHeaderWithRevision()
        {
            return "Header;1.1.1";
        }
    }

二、优秀单元测试的支柱

　　要编写优秀的单元测试，它们应该同时具有 可靠性、可维护性 及 可读性。

2.1 编写可靠的测试

　　一个可靠的测试能让你觉得自己对事态了如指掌，能够从容应对。以下是一些指导原则和技术：

　　（1）决定何时删除或修改测试

　　一旦测试写好并通过，通常我们不应该修改或删除这些测试，因为它们是我们得绿色保护网。但是，有时候我们还是需要修改或者删除测试，所以需要理解什么情况下修改或删除测试会带来问题，什么情况下又是合理的。一般来说，如果有产品缺陷、测试缺陷、语义或者API更改或者是由于冲突或无效测试，我们需要修改和删除测试代码。

　　（2）避免测试中的逻辑

　　随着测试中逻辑的增多，出现测试缺陷的几率就会呈现指数倍的增长。如果单元测试中包含了下列语句就是包含了不应该有的逻辑：

• switch、if或else语句；
• foreach、for或while循环；

　　这种做法不值得推荐，因为这样的测试可读性较差，也比较脆弱。通常来说，一个单元测试应该是一系列方法的调用和断言，但是不包含控制流程语句，甚至不应该将断言语句放在try-catch中。

　　（3）只测试一个关注点

　　如果我们的单元测试对多个对象进行了断言，那么这个测试有可能测试了多个关注点。在一个单元测试中验证多个关注点会使得事情变得复杂，却没有什么价值。你应该在分开的、独立的单元测试中验证多余的关注点，这样才能发现真正失败的地方。

　　（4）把单元测试和集成测试分开

　　掐面讨论了测试的绿色安全区，我们需要的就是准备一个单独的单元测试项目，项目中仅包含那些在内存中运行，结果稳定，可重复执行的测试。

　　（5）用代码审查确保代码覆盖率

　　如果覆盖率低于20%，说明我们缺少很多测试，我们不会知道下一个开发人员将怎么修改我们得代码。如果没有回失败的测试，可能就不会发现这些错误。

2.2 编写可维护性的测试

　　可维护性是大多数开发者在编写单元测试时面对的核心问题之一。为此我们需要：

　　（1）只测试公共契约

　　（2）删除重复测试（去除重复代码）

　　（3）实施测试隔离

　　测试隔离的基本概念是：一个测试应该总是在它自己的小世界中运行，与其他类似或不同的工作的测试隔离，甚至不知道其他测试的存在。

2.3 编写可读性的测试

　　不可读的测试几乎没有任何意义，它是我们向项目的下一代开发者讲述的故事，帮助开发者理解一个应用程序的组成及其开端。

　　（1）单元测试命名

　　这个前面我们讨论过，应该包括三部分：被测试方法名_测试场景_预期行为，如果开发人员都是用这种规范，其他的开发人员就能很容易进入项目，理解测试。

　　（2）变量命名

　　通过合理命名变量，你可以确保阅读测试的人可以尽快地理解你要验证什么（相对于理解产品代码中你想要实现什么）。请看下面的一个例子：

    [Test]
    public void BadlyNameTest()
    {
        LogAnalyzer log = new LogAnalyzer();
        int result = log.GetLineCount("abc.txt");

        Assert.AreEqual(-100, result);
    }

    [Test]
    public void GoodNameTest()
    {
        LogAnalyzer log = new LogAnalyzer();
        int result = log.GetLineCount("abc.txt");
        const int COULD_NOT_READ_FILE = -100;

        Assert.AreEqual(-COULD_NOT_READ_FILE, result);
    }

　　经过改进后，我们会很容易理解这个返回值的意义。

　　（3）有意义的断言

　　只有当测试确实需要，并且找不到别的办法使测试更清晰时，你才应该编写定制的断言信息。编写好的断言信息就像编写好的异常信息，一不小心就会犯错，使读者产生误解，浪费他们的时间。

　　（4）断言和操作分离

　　为了可读性，请不要把断言和方法调用写在同一行。

    // 断言和操作写在了同一行
    Assert.AreEqual(-COULD_NOT_READ_FILE, log.GetLineCount("abc.txt"));

三、小结

　　这一篇我们学习了：

• 尽量将测试自动化，尽可能多次地运行测试，尽可能持续地进行产品交付；
• 把集成测试和单元测试分开，为整个团队构建一个绿色安全区，该区域中所有的测试都必须通过；
• 按照项目和类型组织测试，把测试分别放在不同的目录、文件夹或者命名空间中；
• 使用测试类层次，对一个层次中相关的几个类进行同一组测试，或者对共享一个通用接口或者基类的类型进行同一组测试；
• 优秀单元测试具有三大支柱：可读性、可维护性与可靠性，它们相辅相成。
• 如果人们能读懂你的测试，就能理解和维护测试，如果测试能够通过，它们也会信任测试。一旦实现这个目标，你就能知道系统是否正常工作，具有了处理变更和在需要时修改代码的能力；

附件下载

　　本系列文章的示例代码：点此下载

参考资料

      

　　（1）Roy Osherove 著，金迎 译，《单元测试的艺术（第2版）》

 

作者：周旭龙

出处：http://edisonchou.cnblogs.com

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接。