Java 黄瓜回归成分检验。应测试的层是否有边界？

上周我发现自己不得不开始考虑如何重构一个只包含单元测试的旧应用程序。我的第一个想法是使用Cucumber添加一些组件测试场景，以熟悉业务逻辑，并确保我的更改不会破坏任何东西。但在那一点上，我与我工作的公司的一位架构师进行了一次谈话，这让我怀疑这是否值得，以及我必须实际测试的代码是什么

此应用程序有许多不同类型的端点：要从中调用和要调用的rest端点、Oracle存储过程以及JMS主题和队列。它在一个war文件中部署到Tomcat服务器，到代理的连接工厂和到数据库的数据源在服务器中配置，并使用JNDI获取

我的第一个想法是在一个嵌入式Jetty中加载整个应用程序，指向真正的web.xml，这样所有的东西都会像从生产环境加载一样加载，但随后模拟连接工厂和数据源。通过这样做，可以测试部署应用程序的基础架构的所有连接逻辑。考虑到六边形体系结构，考虑到这些端口逻辑只应用于将接收到的数据转换为应用程序数据，这似乎太费劲了。这不应该只是单元测试吗

我的下一个想法是只模拟存储过程并在测试中加载SpringXMLS，而不使用任何web服务器，这使得模拟类变得更容易。为此，我将对rest端点使用Spring MockMvc和JMS使用Mockrunner等库。但是，这种方法仍然会测试一些适配器，并使测试复杂化，因为测试的结果是XML和JSON有效负载。在这个应用程序中完成的转换相当繁重，相同的消息类型可能包含一个类的不同版本（每条消息可能包含许多实现多个接口的复杂对象）

所以现在我在想，也许最好的方法是从入口点到应用程序创建测试，从适配器调用服务，并验证负责向代理发送消息或调用其他REST端点的服务是否被实际调用。然后，只需确保端点有适当的单元测试，并通过提供一些在真实环境中执行的冒烟测试来验证部署后一切正常。这将测试连接逻辑，业务逻辑将被隔离测试，而不考虑是添加了新适配器还是删除了新适配器

这种方法正确吗？我会不这样做就留下一些东西吗？还是太多了，我应该相信单元测试

---

谢谢。

您的应用程序和环境听起来相当复杂。我肯定想要集成测试。我将按如下方式对应用程序进行外部测试：

• 编写在实际生产环境中针对应用程序运行的冒烟测试套件。黄瓜是一个很好的工具。该套件应该只做生产中安全的事情，并且应该尽可能小，同时让您确信应用程序已正确安装和配置，并且它与其他系统的集成正在工作

• 编写在测试环境中针对整个应用程序运行的验收测试套件。黄瓜在这里也是个不错的选择
  我希望验收测试环境包括一个Tomcat服务器，其中包含生产Tomcat中存在的所有服务的测试版本，以及一个具有与生产相同的模式、存储过程等的数据库（但不包括生产数据）。通过存根和模拟、使用记录/重播库（如和/或自己实现它们的测试版本）来处理您不拥有的外部依赖项。验收测试应该可以自由地对数据做任何事情，而且它们不必担心您不拥有的服务的可用性
  编写足够的验收测试来描述应用程序的主要用例，并测试应用程序各部分（子系统和类）之间的所有重要交互。也就是说，将验收测试用作集成测试。我发现验收测试和集成测试的目标之间几乎没有冲突。但是，不要编写超过规范和集成覆盖率所需的验收测试，因为它们相对较慢

• 单元测试每个做任何有趣事情的类，只留下通过验收测试完全测试的类。因为您已经在进行集成测试，所以您的单元测试可以是真正的单元测试，它可以存根或模拟它们的依赖关系。（尽管让一个经过单元测试的类使用真正的依赖关系并没有错，这些依赖关系足够简单，不会在单元测试中引起问题）

---

衡量代码覆盖率，以确保验收测试和单元测试的结合测试您的所有代码。

据我所知，这种方法与我被告知的诚实相反。我理解首先使用BDD方法编写用例的想法，这就是我想要做的。但是，添加一个在真实环境中运行的验收测试套件不会花费很长时间来测试应用程序吗？我的理解是，您希望有一个测试套件来测试您的业务逻辑，而不依赖任何外部系统（包括BBDD）来加快速度。使用适当的组件测试来验证逻辑只会将测试留在真实的环境中，以验证接线。这就是为什么我建议在当前的单元测试中添加一组使用BDD风格编写的测试，以验证所有可用的不同用例，但仅限于