我上周发现自己不得不开始考虑如何重构一个只包含单元测试的旧应用程序。我的第一个想法是使用Cucumber添加一些组件测试场景，以熟悉业务逻辑并确保我不会因我的更改而破坏任何内容。但是那时我与我工作的公司的一位建筑师进行了对话，这让我想知道它是否值得，以及实际上我必须实际测试的代码。
此应用程序具有许多不同类型的端点：要调用的端点和要调用的端点，Oracle存储过程以及JMS主题和队列。它在war文件中部署到Tomcat服务器，并且代理的连接工厂和数据库的数据源在服务器中配置并使用JNDI获取。
我的第一个想法是将整个应用程序加载到嵌入式Jetty中，指向真正的web.xml，以便加载所有内容，因为它将从生产环境加载，然后模拟连接工厂和数据源。通过这样做，将测试部署应用程序的基础架构的所有连接逻辑。考虑到六边形体系结构，考虑到这些仅仅是逻辑应该只是将接收数据转换为应用程序数据的端口，这似乎是太多的努力。这不应该只是单元测试吗？
我的下一个想法是在没有任何Web服务器的情况下模拟存储过程并在我的测试中加载Spring XML，这样可以更容易地模拟类。为此，我将使用Spring MockMvc等库为其余端点和Mockrunner for JMS。但同样，这种方法仍然会测试一些适配器并使测试复杂化，因为测试的结果将是XML和JSON有效负载。在这个应用程序中完成的转换非常繁重，其中相同的消息类型可以包含不同版本的类（每个消息可以包含许多实现多个接口的复杂对象）。
所以现在我想，也许最好的方法是从入口点到应用程序创建我的测试，从适配器调用的服务，并验证负责向代理发送消息的服务或者实际上调用了其他REST端点。然后确保对端点进行适当的单元测试，并通过提供在真实环境中执行的一些冒烟测试来验证一旦部署后一切正常。这将测试连接逻辑，并且将单独测试业务逻辑，而无需关心是否添加了新适配器或删除了一个。
这种做法是否正确？如果不进行测试，我会留下一些东西吗？或者它仍然太多我应该相信单元测试？
感谢。
答案 0 :(得分：1)
您的应用和环境听起来相当复杂。我肯定想要集成测试。我按照以下方式在外面测试应用程序：
编写一个在实际生产环境中针对应用程序运行的冒烟测试套件。黄瓜将是一个很好的工具。该套件应该只做一些安全的生产，并且应该尽可能小，同时让您确信应用程序已正确安装和配置，并且它与其他系统的集成正在运行。
编写一个在测试环境中针对整个应用程序运行的验收测试套件。黄瓜也是一个不错的选择。
我希望验收测试环境包括一个Tomcat服务器，它包含生产Tomcat中存在的所有服务的测试版本，以及一个与生产（但不是生产数据）相同的模式，存储过程等数据库。通过使用诸如Betamax之类的记录/重放库和/或自己实现它们的测试版本来处理您通过存根和模拟不拥有的外部依赖项。验收测试应该可以自由地对数据做任何事情，并且他们不必担心您不拥有的服务的可用性。
编写足够的验收测试来描述应用程序的主要用例，并测试应用程序各部分（子系统和类）之间的所有重要交互。也就是说，使用验收测试作为集成测试。我发现接受和集成测试的目标之间几乎没有冲突。不要编写比规范和集成覆盖范围更多的验收测试，因为它们相对较慢。
对每个做任何有趣事情的课程进行单元测试，只留下经验收测试完全测试的课程。由于您已经进行了集成测试，因此您的单元测试可以是真正的单元测试，可以对其进行存根或模拟其依赖性。 （虽然让单元测试的类使用简单到足以在单元测试中不会引起问题的真正依赖项没有任何问题。）
测量代码覆盖率以确保验收和单元测试的组合测试所有代码。