unit-testing - 集成测试-可以正确完成吗？

Question

在过去的两年中，我曾将TDD用作某些项目的开发风格，但我始终坚持同一观点:如何测试程序各个部分的集成？

我目前正在做的是为每个类编写一个测试用例(这是我的经验法则:“单元”是一个类，每个类都有一个或多个测试用例)。我尝试通过使用模拟和 stub 来解决依赖关系，这确实很好，因为每个类都可以独立测试。经过一些编码后，将测试所有重要的类。然后，我使用IoC容器将它们“连接”在一起。我被困在这里:如何测试接线是否成功以及对象是否以我想要的方式交互？

一个示例:考虑一个Web应用程序。有一个 Controller 类，它接收一个id数组，使用一个存储库根据这些id来获取记录，然后遍历记录并将它们作为字符串写入外文件。

为简单起见，将提供三个类:Controller，Repository和OutfileWriter。他们每个人都进行了隔离测试。

为了测试“真实”应用程序，我将执行以下操作:使用数据库中的一些ID发出http请求(手动或自动)，然后在文件系统中查找是否写入了文件。当然，该过程可以自动化，但是仍然:那不是重复测试逻辑吗？这就是所谓的“集成测试”吗？在我最近读到的关于单元测试的书中，我觉得集成测试更像是一种反模式？

Answer 1

您所描述的实际上是集成测试(或多或少)。不，它不是反模式，而是sw开发生命周期的必要组成部分。

任何合理复杂的程序都不仅仅是其各个部分的总和。因此，尽管您对进行了单元测试，但对于整个系统是否可以按预期的方式运行，您仍然没有太多线索。

为何如此，有几个方面:

单元测试在隔离的环境中执行，因此它们无法说出程序中各个部分在现实生活中如何协同工作。

是“单元测试者的帽子”，很容易限制人们的视线，因此，开发人员根本无法识别出一整类因素，这些都是需要测试的因素*

即使是

，也有一些不能在单元测试中进行合理测试的东西-例如如何测试您的应用服务器在高负载下是否仍然存在，或者在请求过程中数据库连接是否断开？

*我刚刚从卢克·霍曼(Luke Hohmann)的著作《超越软件体系结构》中读到一个示例:在一个通过在实际机器中创建并维护硬件组件ID的“快照”而应用了强大的反盗版防御功能的应用程序中，开发人员的代码涵盖了单元测试。然后，质量检查人员通过在没有网卡的计算机上试用该应用程序，使该应用程序在10分钟内崩溃了。事实证明，由于开发人员在Mac上工作，他们认为该机器具有网卡，其MAC地址可以合并到快照中，这是理所当然的……