我有一个 WCF 服务，该服务运行并与数据库、文件系统和少量外部 Web 服务交互，然后创建结果并对其进行 Xml 序列化并最终返回。
我想为这个解决方案编写测试并且我正在考虑如何(它全部使用依赖注入(inject)和按契约(Contract)设计)。
我可以采用 3 种主要方法。
1) 我可以选择最小的代码/方法单元并为其编写测试。选择一个类并将其与其依赖项(其他类等)隔离开来。虽然它保证了质量，但是编写它们需要花费很多时间而且速度很慢。
2) 仅使与外部系统的交互可模拟，并编写一些涵盖从发出请求到响应被序列化并返回的主要场景的测试。这将测试我的类之间的所有交互，但会模拟所有外部资源访问。
3) 我可以设置一个测试环境，在其中与外部 Web 服务进行交互，进行文件访问，进行数据库访问等。然后从头到尾编写测试。这需要环境设置和对所有其他系统的依赖才能启动和运行。
关于 #1，我认为没有必要投入时间/金钱/精力为我拥有的每个方法或代码编写测试。我的意思是这是浪费时间。
关于#3，由于它依赖于外部资源/系统，因此很难设置和运行它。
#2，听起来对我来说是最好的选择。因为它将测试它应该测试的内容。只有我的系统及其所有类并模拟所有其他外部系统。
基本上，经过多年的单元测试经验，我得出的结论是，编写单元测试是一种应该避免的浪费，而孤立的系统测试才是最好的投资返回。
即使我打算先编写测试 (TDD) 然后再编写生产代码，我认为仍然是 #2 最好。
您对此有何看法？您会为您的应用程序编写小型单元测试吗？您认为这是时间/预算/精力的最佳实践和最佳利用方式吗？
最佳答案
如果你想谈论质量，你应该拥有所有 3 个:
- 单元测试以确保您的代码按照您的想法行事，公开任何边缘情况并帮助 regression .您(开发人员)应该编写此类测试。
- 集成测试以验证整个过程的正确性，组件之间对话是否正确等等。同样，您作为开发人员编写此类测试。
- 在类似生产的环境中进行系统范围的测试(自然有一些限制 - 您可能无法访问客户端数据库，但您应该在本地计算机上拥有它的精确副本)。这些测试通常由专门的测试人员编写(通常使用不同于应用程序代码的编程语言)，但当然也可以由您编写。
第二和第三类测试(集成和系统)将花费太多精力来测试较小组件的边缘情况。这就是您通常想要进行单元测试的目的。您需要集成，因为在连接经过测试、验证和正确的模块时可能会出现某些问题。当然，系统测试是您在开发期间每天做的事情，或者指派人员(手动测试人员)做的事情。
从列表中进行选定类型的测试可能会在某种程度上起作用，但远非完整的解决方案或高质量的软件。
关于asp.net - 如何为系统编写开发人员测试(单元测试、集成测试等)？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15691225/