何时用集成测试替换单元测试

最新推荐文章于 2022-08-27 13:56:52 发布

danpu0978

最新推荐文章于 2022-08-27 13:56:52 发布

阅读量236

点赞数

文章标签：单元测试数据库 python java 人工智能

我考虑整合与单元测试已经有一段时间了。大量的谷歌搜索，堆栈中的问题溢出并查看许多书。在这篇文章中，我想与大家分享我所发现的信息以及我对此做出的决定。

我认为，如果您将这个问题提交给任何Java开发人员，您将立即获得支持单元测试的答案。他们会告诉您，如果您不能进行单元测试，则您编写的代码单元很大，您必须将其分解为多个可测试的单元。我在堆栈溢出中发现了这些问题

有助于更好地理解这两种术语。

在Java域中，单元测试得到了广泛的关注，现在大多数项目都执行代码覆盖和单元测试。集成测试是一个相对较新且被误解的概念。即使实践不到，单元测试也可以有多种用途。让我们看一个简单的用户故事，然后重新访问它们。

让我们通过用户故事来考虑

用户将以UI形式给出INPUT，并且当单击Submit按钮时，PROCESSED输出将显示在下一页中。由于结果应该是可编辑的，因此INPUT和OUTPUT都应保存在数据库中。

技术设计

让我们假设我们的应用程序将来会Swift增长，现在我们就牢记这一点进行设计。

如上图所示，它是带有视图，服务和视图的标准4层设计。它具有一个应用程序层，其中包含如何将输入转换为输出的逻辑。为了实现这个故事，我们编写了5种方法（1种在使用中，2种用于保存输入和输出的dao，1种包含业务和1种在视图层中用于准备输入的方法。）

编写一些单元测试用例

如果要对故事进行单元测试，则需要编写5个测试。由于不同的层是相关的，因此我们可能需要使用模拟对象进行测试。但是，除了应用程序层中执行原始过程的一种方法之外，是否还需要对另一部分进行单元测试？例如方法

public void saveInput(Input input){  
           Session session = sessionFactory.getCurrentSession();  
           session.save(input);  
 }

当您对此进行单元测试时，通常将使用sessionFactory的模拟对象，并且代码将始终有效。因此，在这里进行单元测试的接线没有多大意义。如果您仔细观察，除了应用程序层之外，所有其他方法都将与我们所讨论的类似。

集成测试可以实现什么？

阅读此处，以进行集成测试。正如我们所看到的，这个故事的大多数单元测试都没有效果。但是我们不能跳过测试，因为我们想找出代码覆盖范围并进行代码自测。根据Martin flower在他关于持续集成的文章中，您应该编写可以测试其他代码的代码。我认为良好的集成测试可以为您做到这一点。

让我们针对这种情况编写一个简单的集成测试，

@Configurable(autowire = Autowire.BY_NAME)   
 @RunWith(SpringJUnit4ClassRunner.class)   
 @ContextConfiguration(locations = {"classpath:applicationContext.xml"})  
 public class SampleIntTest {  
      @Autowired  
      private SamService samService;  
      @Test  
      public void testAppProcessing(){  
      Input input = new Input();  
      //prepare input for the testing.  
      Output output = samService.processInputs(input);  
      //validate outpt gainst the given input.  
      if(!isValidate(input,output)){  
           Assert.fail("Validation failed!");  
      }  
 }

我在这里跳过了视图层，因为它不太相关。我们期望在bean Input中从UI获得INPUT，这就是我们将在服务层中得到的。在这里，通过几行编码，您可以从服务层实现应用程序的全部功能。

最好使用像H2这样的内存数据库来进行集成测试。如果表结构很复杂，则在这种情况下可能无法实现，您可以使用数据库的测试实例并准备脚本以删除所有数据，并将其作为测试的一部分运行，以便恢复数据库状态。这很重要，因为在下一次运行中，将再次保存相同的数据。

集成测试的另一个优点是，如果您要更改实现，则无需更改测试，因为它与输入和输出有关。这对于重构代码而不更改测试代码很有用。另外，您可以安排这些测试来衡量应用程序的稳定性，并且可以尽早发现任何回归问题。

正如我们已经看到的，集成测试易于编写并且很有用，但是我们需要确保它不会完全取代单元测试。只要有一个基于规则的系统（例如我们的案例中的LogicalProcesser），它就必须是强制性的，因为您无法使用集成测试来涵盖所有情况。

因此，JEE一如既往地致力于选择并坚持下去。在过去的几个月中，我们一直在团队中进行练习，而且进展顺利。当前，我们使集成测试成为必需，单元测试和可选。始终检查代码覆盖范围，并确保您对系统核心（本例中的LogicalProcesser）具有良好的覆盖率。

参考： 何时由我们的JCG合作伙伴 Manu PK在“面向对象的生活”博客中用集成测试替换单元测试。

相关文章：