英文原文：Top 5 Reasons to Use a Mocking Framework

背景

研究人员和专家已经声明了敏捷和单元测试的主流.如果你所使用的正好在主流框架中那是个好消息。但是如果你的公司被夹在漩涡中间怎么办？现在你正在试图让你的公司加快速度并且对你的代码库添加单元测试，但是你从哪里开始动手呢？

自从NUnit第一次发布我就一直对我的.net程序做单元测试，并且练习使用测试驱动开发和行为驱动开发至少六年时间。你可以从我发的博客和我所说的话中发现，我是一个超级粉丝。但是入门是很困难的。需要花费时间，但是花费时间是很值得的。收获是很大的并且也得到了很好的证明。

写第一个测试时，从没有测试过度到一个测试测试，通常是一件最困难的事情。你从哪里开始着手开始呢？第一件你需要做的事就是(get a grip on mocking)，但我的意思意思不是去取笑其他的开发人员。为什么你应该使用mocking框架呢？如果没有mocking 框架你不能高效的独立开单元测试。你可以看下我发在Why Mocking Matters上的博客和 I Got StartedMocking。

我对我写的这些博客很自豪，让我们谈论一些可能(hit closer to home)的原因，根据这些原因，让我给你介绍一下我使用mocking框架的5个首选的理由。

5. 80年代的人呼吁重用以前的代码

而今SOLID（单一职责原则，开放封闭原则，里氏替换原则，接口隔离原则和依赖倒置原则的首字母组合）不再是时尚者使用的专有名词。它是软件开发的黄金手册。但是如果你还是继承自软盘时代开发软件的，那么是时候和它一刀两断了。

你想重构你的代码使之更坚硬至少不会湿软软的[@Lesue 注：SOLID的字面字面意思是坚硬的，所以这里是谐意，代指更符合5大原则]。在现代的软件开发中，我们已经吸取经验了一件事：不要改变你的代码，除非你可以使用测试验证这些改变的作用。而且在能够测试之前，很多遗留的代码也需要修改。[有点像]鸡与蛋的关系。

在模拟框架中这种情形是有所考虑的。它有为将来、使用静态的/私有的/密封的对象、使用示例以及一些其它特性来模拟测试的能力，你可以在你的应用里创建隔离带就地运行这些测试，并且保证了重构不会带来你不希望有的副作用。

Spray of Light/ Fernando de Sousa/ CC BY

4. 应用程序是工作单元

依赖注入用来阻止得流感的，不对吗？严肃的说，依赖注入是SOLID中最重要的那一部分，很受争议。在应用程序中，你看基本代码是没有依赖注入或者任何分隔实例的，并且每个代码内部都有5,000行的代码。工作单元（测试单元）是代码最小隔离的地方。在完美的世界中，.NET就是个方法。在这种情况下最小的隔离测试单元工作好，那么整个应用也就没问题啦[@Lesus注：你若安好，便是晴天]。

这就是模拟测试框架所带来将来使用一个对象模拟测试的能耐。将来模拟测试特性允许你在你的测试单元里创建一个固定的模拟测试对象，在你进行测试时加入系统中，即使是在进行测试时这个系统需要显式实例化这个对象。

Daily injection/ Sarah G/ CC BY

3. Where 子句?  我们不需要讨厌 where 子句!

你花了许多时间从测试数据库准确无误的获取数据。你可以高效的测试你的软件并得到预期的结果。就算这样，其实它并不是真正的单元测试，因为应用程序才是工作单元（见上面的原因#5）。但是你已经进步了！

忽然，你的所有测试都失败了。你花了将近一整天时间试着找出来是哪里出了问题。最终，你发现（通常是偶然的）有人执行了"delete from customer"，并且抹去了你的所有数据。而幸好你做了备份！

通过抽象出依赖 ，将对数据访问的调用替换为mocks，你可以阻止这个问题。每个mock都是安排来给测试提供所需要的数据的，并不需要实际访问数据库。这消除了可能导致单元测试失败的，外在的系统失效或变化所带来的干扰。

Ipswich, Waterfront, Ipswich Campus, The Big Question Mark Sculpture/ Martin Pettitt /CC BY

2. [Ignore] 是代码库中最受欢迎的属性

在你之前的某个人做了增加单元测试的勇敢尝试，并配置了构建服务器来运行这些单元测试，如果任意一个测试失败了，整个构建也会失败。干得好！可是，开发者要么离开了这个项目，要么被遗留的代码库折磨到投降，所以放弃了。现在，不需要维护单元测试，每次只要给失败的测试标上Ignore 属性，它们就不会运行，这样就不会破坏构建。

具有太多固定依赖的测试是内在脆弱的。系统中测试范围内需要运行的所有东西，就是工作单元。所有其他的依赖需要用fakes 或 mocks(假冒或模拟)替换。Fakes 对开发者是一个残酷打击，因为它们的维护工作量巨大。针对测试的依赖性，模拟出整个系统，这样就隔离了测试所需要实现的范围以外的变化，这使得它不那么脆弱，更有可能被维护。当一个失败的测试是个例外而不是这种规则，一般需要修复它而不是忽略(ignore)它。

Ignore/ Frank Hebbert /CC BY

接下来排在第一的使用模拟测试框架的理由是……

1. 你的同事编码很弱

你不停的收到指定给你的bug，但每次都发现bug实际上你代码依赖的对象出了问题。而每次你都不得不去修复它。Bug的数量不停的增加，你发现你就像在买一周一次的甜甜圈，甚至照成这些问题的代码都不是你编写的！

解决方案？不要依赖这些代码。在开发中使用单元测试来操练你编写的代码，用Mocking框架来隔离所有的依赖。这样，当bug出现时，你可以核实你开发的软件能像预期一样的工作，那么问题是其他人问题。

Noah with his new paper bag hat/ ella /CC BY

摘要

显然，这篇文章写得有些挖苦。不幸的是，我在软件开发职业生涯中遇到了这些情况中的每一个。要了解更多 JustMock 如何可以帮助您解决它们和任何你其它的软件噩梦，请下载一个免费试用版，今天就试试吧！

你使用模拟框架的原因是什么？在这里发布你的评论吧。我会根据评论写一个跟进的5大原因，如果你是第一个提出某个被跟进发布的文章选定的建议的人，会得到JustMock的免费许可！

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务