我有一个WCF服务，它运行并与数据库，文件系统和少量外部Web服务交互，然后创建结果并Xml序列化它并最终返回它。
我想为这个解决方案编写测试，我正在思考如何（通过合同使用依赖注入和设计）。
我可以采取三种主要方法。
1）我可以选择最小的代码/方法单元并为其编写测试。选择一个类并将其与其依赖项（其他类等）隔离。虽然它保证了质量，但它需要花费大量时间来编写它们，而且速度很慢。
2）只允许与外部系统的交互可模拟，并编写一些测试，涵盖从发出请求到响应被序列化和返回时的主要场景。这将测试我的类之间的所有交互，但模拟所有外部资源访问。
3）我可以设置一个测试环境，其中与外部Web服务的交互确实发生，文件访问发生，数据库访问发生等等。然后从头到尾编写测试。这需要环境设置和所有其他系统的依赖性才能启动和运行。
关于＃1，我认为投入时间/金钱/精力来编写我所拥有的每种方法或代码的测试都没有意义。我的意思是浪费时间。
关于＃3，因为它依赖于外部资源/系统，所以很难将其设置并运行。
＃2，听起来对我来说是最好的选择。因为它将测试它应该测试什么。只有我的系统及其所有类，并嘲笑所有其他外部系统。
基本上，经过多年的单元测试经验，我的结论是编写单元测试是一种浪费，而且隔离系统测试是最佳的投资回报。
即使我打算首先编写测试（TDD），然后是生产代码，我认为仍然是＃2。
您对此有何看法？你会为你的应用程序编写小型单元测试吗？你认为这是一个好的做法，最好地利用时间/预算/能源吗？
答案 0 :(得分：1)
如果你想谈论质量，你应该拥有全部3：
第二种和第三种类型的测试（集成和系统）将花费太多精力来测试较小组件的边缘情况。这是您通常需要进行单元测试的内容。您需要集成，因为在连接经过测试，验证且正确的模块时可能会失败。当然，系统测试是您每天，开发期间或指定人员（手动测试人员）执行的操作。
从列表中选择所选类型的测试可能会有所作为，但远不是完整的解决方案或质量软件。
答案 1 :(得分：1)
所有3个都很重要，针对不同的测试类型，这是一个单元/集成/系统类别的矩阵，每个类别都有正面和负面测试。
对于代码覆盖率，单元测试将产生最高百分比，然后是Integration then System。
您还需要考虑测试的目的是否是验证（将满足最终用户\客户要求，即价值）或验证（写入规范，即正确）。
总之，答案是“它取决于”，我建议遵循SEI CMMi模型进行验证和验证（即测试），该模型以每项活动的目标（价值）开始，然后使该活动受到最终的措施的影响。允许整个过程不断改进。通过这种方式，您可以从How中分离出什么和为什么，您将能够为您的特定环境（可能是生命支持系统或当天的推文）回答您最喜欢的姨妈，App的时间和价值类型问题）。
答案 2 :(得分：0)
摘要：＃2（集成测试）似乎最符合逻辑，但您应该毫不犹豫地使用各种测试来实现最需要它的代码库的最佳覆盖范围。对“一切”进行测试的拍摄不是一个有价值的目标。
长版
有一种思想流派在那里，开发人员确信采用单元\集成\系统测试意味着努力争取每一个被测试的代码。它要么根本没有测试覆盖，要么承诺测试“一切”。这种二元思维总是使采用任何一种测试策略看起来都非常昂贵。
事实是，强制每行代码\ function \ module都要测试，就像编写所有代码一样快。这需要花费太多的时间和精力，而且大多数都会带来很少的回报。另一个事实是，你无法在一个非平凡的项目中实现真正的100％覆盖率。
测试不是自己的目标。它是实现其他目标的一种手段：最终产品质量，可维护性，互操作性等，同时花费尽可能少的努力。
考虑到这一点，退一步评估您的具体情况。为什么要“为此解决方案编写测试”？您对今天项目的整体质量不满意吗？您是否经历过高回归率？您是否可能不确定某些模块是如何工作的（更重要的是，它可能存在哪些错误）？无论您的确切目标是什么，您都应该能够选择带来特殊挑战的作品，并将注意力集中在它们上面。根据这些部分的不同，可以选择适当的测试方法。
如果您有一个特别棘手的功能或类，请考虑对它们进行单元测试。如果您遇到了一个复杂的架构，其中有多个难以理解的交互，请考虑编写集成测试，为最棘手的场景建立一个干净的基线，并更好地了解问题的来源（您可能会清除一些错误）方式）。如果您的问题没有在更局部化的测试中得到解决，系统测试可以提供帮助。
根据您为特定场景提供的信息，面向外部的单元测试\集成测试（＃2）看起来最有希望。看起来你有很多外部依赖，所以我猜这是大多数复杂性隐藏的地方。综合单元测试（＃1）是＃2的超集，所有额外的内部资料都带有可疑价值。 ＃3（完整的系统测试）可能不允许你测试外部边缘情况\错误条件以及你想要的。