首先,我认为我们应该正确使用术语。在测试(简化)中有两组通用的“假”对象:一个模拟,它在预定义的输入和存根上返回预定义的答案,它是 SUT(被测系统)与之通信的对象的简化版本。虽然模拟基本上只提供响应,但存根可能使用实时算法,但不会将其结果存储在数据库中或通过电子邮件发送给客户。我不是测试专家,但这两个假对象更适合在单元中使用,具体取决于它们在验收测试中的范围。
因此,您的 sut 在集成测试期间与远程系统通信。在我的书中,这是实际测试您的软件如何与其他系统集成的最佳时机,因此您的软件应该针对远程系统的测试版本进行测试。如果这是不可能的(他们可能没有测试系统),你在概念上就会遇到某种麻烦。您只能以您期望它工作的方式塑造您的存根或模拟,非常类似于您为与远程服务通信而编写的软件部分。这遗漏了一些您想要通过集成测试进行测试的重要事项:客户端是否正确实施,以便它可以与实时服务器一起使用。由于服务器端存在实现错误,我们是否必须开发工作?与远程系统的通信会在多大程度上影响我们软件的性能?我们的身份验证凭据有效吗?身份验证机制是否有效?这种迄今为止没人想到的沟通关系的技术和概念含义是什么? (相信我,后者会比你想象的更频繁地发生!)
一般来说:如果您针对 mock 或 stub 进行集成测试,会发生什么情况是您根据自己对如何实现客户端和服务器端通信的理解进行测试,而不是测试客户端的工作方式使用实际的远程服务器,或者至少是旁边最好的东西,一个测试系统。我可以根据经验告诉你:永远不要对远程系统的行为做出假设——测试它。即使在谈论 JMS 服务器时:测试一下!
如果您为一家公司工作,则针对提供的测试系统进行测试更为重要:如果您的软件针对测试系统工作并且您可以证明它(硒在这里是一个很好的帮手,以及良好的日志记录,信不信由你)并且您的软件无法与实时版本一起使用,您遇到了一种我称之为“instablame”的情况:很明显,软件无法正常运行并不是您的错。我自己讨厌指手画脚,但大多数西装往往会问“是谁的错?”甚至在“我们可以立即解决这个问题吗?”之前在“我们如何解决这个问题?”之前。还有一组特殊的诉讼叫律师,你知道的...... ;)
话虽如此:如果您在集成测试期间绝对必须使用这些存根,我将为它们创建一个自己的项目(比如说“MyProject-IT-Stubs”并在运行之前构建并运行最新版本的MyProject-IT-Stubs我的主要项目的IT。使用maven时,您可以使用war打包创建MyProject-IT-Stubs,在预集成测试阶段将其称为依赖项,并在同一阶段为这场战争启动码头。然后您的集成测试运行,无论成功与否,您都可以在集成测试后阶段拆除码头。
恕我直言,使用 maven 组织项目的最佳方法是创建一个包含三个模块的项目:MyProject、MyProject-IT-Stubs 和 MyProject-IT(声明对 MyProject 和 MyProject-IT-Stubs 的依赖关系。这样可以保留您的项目漂亮整洁,存根不会污染您的项目。您可能还想考虑将MyProject-IT-Stubs 组织成模块,一个用于您必须与之交谈的每个远程系统。一旦您拥有测试访问权限,您就可以简单地停用MyProject-IT-Stubs中的相应模块。
我确信InsertYourBuildToolHere 存在相应的选项。