假设我正在开始一个新项目，质量是首要任务。
我计划进行广泛的单元测试，在我开发架构时要记住哪些重要因素，以便进一步简化单元测试？
编辑：我以前读了一篇文章（我现在找不到），谈论如何在单元测试时将实例化代码与类行为解耦可能会有所帮助。这就是我在这里寻求的那种设计技巧。
答案 0 :(得分：4)
通过能够替换您的方法与测试代码（模拟，假货等）的许多依赖关系，可以轻松进行测试目前推荐的实现方法是通过依赖倒置，即好莱坞原则：“Don打电话给我们，我们会打电话给你。“换句话说，你的代码应该“求东西，不要寻找东西。”
一旦你开始这样思考，你会发现代码很容易依赖很多东西。您不仅依赖于其他对象，还依赖于数据库，文件，环境变量，OS API，全局变量，单例等。通过坚持良好的体系结构，您可以通过适当的层提供这些依赖项，从而最大限度地减少这些依赖项。因此，当需要测试时，您不需要一个充满测试数据的工作数据库，您可以简单地用模拟数据对象替换数据对象。
这也意味着您必须从对象执行中仔细挑选对象构造。放置在构造函数中的“new”语句生成一个很难用测试模拟替换的依赖项。最好在via构造函数参数中传递这些依赖项。
另外，请记住Demeter法则。不要在对象中深入挖掘多个图层，否则就会创建隐藏的依赖项。调用Flintstones.Wilma.addChild（鹅卵石）;意味着你认为对“摩登原始人”的依赖真的是对“摩登原始人”和“威尔玛”的依赖。
答案 1 :(得分：1)
通过使代码高度内聚，低度去耦，确保您的代码可以测试。并确保您知道如何使用模拟工具来模拟单元测试期间的依赖关系。
我建议您熟悉SOLID principle，以便编写更可测试的代码。
答案 2 :(得分：1)
您可能还想查看这两个SO问题：
答案 3 :(得分：1)
一些随意的想法：
定义接口：将功能模块相互分离，并决定它们如何相互通信。接口是不同模块的开发人员之间的“契约”。然后，如果您的测试在接口上运行，那么您要确保团队可以将彼此的模块视为黑盒子，因此可以独立工作。
首先构建并测试至少UI的基本功能。一旦您的项目可以与您“交谈”，它可以告诉您哪些是有效的，哪些不是......但仅限于如果不是骗你的话（额外奖励：如果您的开发人员别无选择，只能使用用户界面，您将很快发现易用性，工作流程，等的任何缺点。）
以最低的实际水平进行测试：您对小部件的工作越有信心，就越容易将它们组合成一个整体。
在开始编码之前，根据规格为每个功能编写至少一个测试。毕竟，这些功能是客户购买产品的原因。确保它的设计是为了做它应该做的事情！
当它做了应该做的事情时，不要满足;确保不做 ，与冲突的应用程序一起运行它。您的客户会。
答案 4 :(得分：0)
您的测试只会满足您的要求。它们可以是您一次性预先提出的要求，它们可以是您在添加功能时一次提出一个要求，或者它们可能是您在发货后提出的要求并且人们开始报告一堆船的虫子，但如果没有人能够或将会准确记录该物应该做什么，你就不能写出好的测试。