单元测试和测试驱动开发的一些常见问题总结

此文收集一些平时使用单元测试碰到的问题和解决办法，供大家参考。

如何检查返回的集合类是否符合期望？

Microsoft UnitTestFramework	如果需要元素的顺序一致，可以使用CollectionAssert.AreEqual；如果不需要考虑顺序，可以使用CollectionAssert.AreEquivalent。（有的地方说MSTest的Assert.AreEqual支持集合类型比较，我测试过，忽悠人的）
nUnit	同上
xUnit	xUnit的Assert.Equal(c1, c2)可以支持集合类型比较，c1和c2的元素顺序必须一致

Microsoft UnitTestFramework / nUnit / xUnit 比较，使用哪个框架更合适?

Microsoft UnitTestFramework和nUnit的用法非常类似，而xUnit由于吸取了nUnit的设计上的经验，用法更加简洁。下面是周公写的两篇文章，nUnit和xUnit介绍的非常详细，大家可以阅读一下：

• 在.NET开发中的单元测试工具之(1)——NUnit
• 在.NET开发中的单元测试工具之(2)——xUnit.Net

什么是Mock？

单元测试的目标是一次只验证一个方法，小步的前进，细粒度的测试，但是假如某个方法依赖于其他一些难以操控的东东，比如说网络连接、数据库连接、系统时间、或者是Servlet容器，那么我们该怎么办呢？要是你的测试依赖于系统的其他部分，甚至是系统的多个其他部分呢？在这种情况下，倘若不小心，你最终可能会发现自己几乎初始化了系统的每个组件，而这只是为了给一个测试创造足够的运行环境让它们可以运行起来。忙乎了大半天，看上去我们好像有点违背了测试的初衷了。这样不仅仅消耗时间，还给测试过程引入了大量的耦合因素，比如说，可能有人兴致冲冲地改变了一个接口或者数据库的一张表，突然，你那卑微的单元测试的神秘的挂掉了。在这种情况发生几次之后，即使是最有耐心的开发者也会泄气，甚至最终放弃所有的测试，那样的话后果就不能想像了。

再让我们看一个更加具体的情况：在实际的面向对象软件设计中，我们经常会碰到这样的情况，我们在对现实对象进行构建之后，对象之间是通过一系列的接口来实现。这在面向对象设计里是最自然不过的事情了，但是随着软件测试需求的发展，这会产生一些小问题。举个例子，用户A现在拿到一个用户B提供的接口，他根据这个接口实现了自己的需求，但是用户A编译自己的代码后，想简单模拟测试一下，怎么办呢？这点也是很现实的一个问题。我们是否可以针对这个接口来简单实现一个代理类，来测试模拟，期望代码生成自己的结果呢？幸运的是，有一种测试模式可以帮助我们：mock对象。Mock对象也就是真实对象在调试期的替代品。

什么时候需要使用Mock？

关于什么时候需要Mock对象，Tim Mackinnon给我们了一些建议：

• 真实对象具有不可确定的行为(产生不可预测的结果，如股票的行情)
• 真实对象很难被创建(比如具体的web容器)
• 真实对象的某些行为很难触发(比如网络错误)
• 真实情况令程序的运行速度很慢
• 真实对象有用户界面
• 测试需要询问真实对象它是如何被调用的(比如测试可能需要验证某个回调函数是否被调用了)
• 真实对象实际上并不存在(当需要和其他开发小组，或者新的硬件系统打交道的时候，这是一个普遍的问题)

如何使用Mock？

.NET Mock Framework有哪些，可以看看下面几个网页：

• .NET Mocking Framework对比
• What C# mocking framework to use?
• The Fakes Framework in Visual Studio 2012

关于Mock框架的实现方式，大概有两种：基于动态代理实现；基于编译时静态织入实现。各个框架的用法看一下介绍很快就可以掌握了，关键是如何使用各种mock技术，存在的争论主要有下面几个：

• 争论一：像Typemock、Moles、Visual Studio 2012 Fakes Framework这类静态织入技术的框架，可以支持对Sealed Class、Non-Abstract Method、Non-Virtual Method、Static Method的Mock。有些人觉得这很强大，有些人觉得这反倒不好，他们认为像Moq、Rhino Mocks这类的框架，正因为不支持前面说的四类情况的mock，强迫项目必须实现依赖倒置，从而降低了项目的耦合性，以达到较高的可测试性以及可维护性。
• 争论二：在使用动态代理方式的Mock框架时候，为了“可测试性”，protected方法必须是virtual的，因为我们需要在子类中进行override。同理，Mock框架能够辅助的方法也必须是virtual的，即使是一个public方法。那么，您觉得这是为了可测试性而做出的让步吗？或者换句话说，您觉得，一个不可以override的protected方法，但是会影响到其他公开接口的功能，这是不是一个合理的设计呢？如果这是一个合理的设计，又不想作出这样的让步……我们又该怎么做呢？（这段话摘自老赵的“与protected成员有关的单元测试方式”）
• 争论三：在使用动态代理方式的Mock框架时候，为了测试一些Non-Abstract Method、Non-Virtual Method、Static Method，提供一个被测方法/类的Wrapper，封装对无法直接访问方法的调用，是否合适？做法参考：
  http://blog.zhaojie.me/2009/08/unit-test-protected-method.html#comment_iX2whQ8q04I003i2
  http://blog.zhaojie.me/2009/08/unit-test-protected-method.html#comment_iX2whQ8q04I003hi

关于争论一，我的考虑的结果如下：

实际情况中，我会根据项目实际情况来选型。考虑的因素主要有：

• 是否需要支持私有方法、Non-virtual方法的单元测试：实际情况中，项目的代码结构不一定是想象中的理想情况，这个时候就需要考虑Typemock、Visual Studio 2012 Fakes这类框架。
• 开发效率：能够花最小的成本完成单元测试工作，获得最大的收益。使用复杂，开发效率低的框架的优先级自然要排在后面。
• 集成难易程度：一般单元测试用例会在提交代码的时候跑一遍，作为保证提交代码质量的一道关卡。单元测试框架是否能和现有持续集成工具很好的集成在一块，也是要考虑的因素。
• 运行效率：跑的越快的框架，能够减少每次验证的时间成本。

什么是“测试驱动数据库开发”？

测试驱动数据库开发，也称为TDDD（Test-Driven Database Development），是把TDD的理念运用到数据库开发的过程中，通过数据库测试来定义数据库的行为，如同通过测试定义应用程序代码逻辑一样，来保证数据库重构过程中的质量。

使用 TDDD 的优点包括：

• 首先，所有TDD的优点都适用与TDDD ,你可以小步而安全的前进；
• 通过重构使系统在整个生命周期中保持高质量的设计；
• 回归测试让你能尽早发现缺陷；
• TDDD促使你能时刻获得一个最新的可执行的系统（而不像传统的设计文档）。

推荐感兴趣的朋友看看伍斌老师翻译《测试驱动数据库开发——Test-Driven Database Development: Unlocking Agility》这本书：

目录结构：http://my.safaribooksonline.com/book/databases/database-design/9780132776486

伍斌老师的译者序：让数据库应用开发不再裸奔——Test-Driven Database Development译者序

样章试读：http://ptgmedia.pearsoncmg.com/images/9780321784124/samplepages/032178412X.pdf

原作者Max Guernsey的PPT：http://www.maxthe3rd.com/test-driven-database-development/TDD-Database.pdf

如何做测试驱动数据库开发？

由于这块研究不深，暂时列举一些数据库单元测试框架，未来如果研究更加深入了，再专门写文章介绍。

数据库单元测试的框架：

• DbFit
• tSQLt（Test Driven Database Development with tSQLt）
• DbUnit

 

参考：

• 简​述​M​o​c​k
• 使用Mono.Cecil解决无法Mock非虚方法和密闭类的问题
• protected成员有关的单元测试方式
• 如何 Mock 非虚方法和密封类？
• 了解何时使用 Override 和 New 关键字（C# 编程指南）
• C# 类教程－多态性
• Visual studio 2012 Fakes
• Apply Test-Driven Development to your Database Projects（中文版）
• 关系数据库测试驱动开发