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

时间 2019-11-10

标签单元测试驱动开发一些常见问题总结繁體版

原文原文链接

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

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

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介绍的很是详细，你们能够阅读一下：git

什么是Mock？

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

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

何时须要使用Mock？

关于何时须要Mock对象，Tim Mackinnon给咱们了一些建议：sql

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

如何使用Mock？

.NET Mock Framework有哪些，能够看看下面几个网页：数据库

关于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这类框架。
开发效率：可以花最小的成本完成单元测试工做，得到最大的收益。使用复杂，开发效率低的框架的优先级天然要排在后面。
集成难易程度：通常单元测试用例会在提交代码的时候跑一遍，做为保证提交代码质量的一道关卡。单元测试框架是否能和现有持续集成工具很好的集成在一块，也是要考虑的因素。
运行效率：跑的越快的框架，可以减小每次验证的时间成本。