如何确保单元测试在这种情况下保持正确？

Question

我真的不知道如何简明扼要地解释我的情况，所以我必须描述一下场景。

我有一个进程 A，它接受输入 X 并产生输出 Y。我有一个单独的进程 B，它接受输入 Y（来自进程 A）并产生输出 Z。

流程 A 和 B 都很复杂，因此可以从单元测试中受益。进程 A 和 B 也可能会发生变化，因此“中间”格式 Y 也会发生变化。

如果我只是对具有输入 Y 的 B 进行单元测试，如果流程 A 发生变化，我如何确保它们保持相关和正确？例如，进程 A 将输入“foo”转换为“bar”。 B 的单元测试将“bar”作为输入并将其转换为“溢出”。如果进程 A 发生变化，现在将“foo”变成“fish”，那么我对 B 的单元测试仍然会通过，但它们的价值值得怀疑，因为它们不再测试预期的输入。

解决这种情况的最佳做法是什么？这种情况有名字吗？

另外（为了增加复杂性），进程 B 是 Java，而进程 A 是 Visual Basic。

我知道“超越”单元测试并执行集成测试将是确保输入 X 可以成为输出 Z 的一种方式，但由于我们对流程 B 进行了大量测试，我们如何确保这些测试保持相关性? （而且当一个是 Visual Basic 另一个是 Java 时也不容易）。

Answer 1

我想您已经知道答案了：集成（端到端）测试。如果设置不可行，您可以做的最好的事情是分别测试 X/Y 和 Y/Z，并确保每当一个中断（由于代码更改）时，您更新另一个以保持测试数据的相关性。

在我看来，投资设置适当的集成测试套件要安全得多，尤其是当端到端流程符合您用户的期望时。最后，他们不会关心你的任何好的单元测试，他们只是想看到你的软件为他们的特定输入做特定的事情。因此，编写端到端的行为测试更具前瞻性，并且可以很好地记录您的软件的功能。

Answer 2

让不同的系统相互通信是一个非常常见的问题，并且没有一个正确的解决方案。然而，在这个问题的每个实例中，都有两种方法可以解决它，您的解决方案将是两者的某种平衡。

1. 测试交互

   正如您所建议的，端到端集成测试对于您的应用程序的成功至关重要。与单元测试相比，它们更复杂，更容易失败，但它们对它来说更加必要。如果您没有适当的集成测试（无论“适当”对您的应用程序意味着什么），您根本无法知道您的应用程序可以正常工作 - 您的单元测试将在真空中通过。

   您如何做到这一点取决于您的应用程序及其依赖项的业务关键程度。如果您的整个生计都依赖于信用卡交易的成功和安全处理，那么您最好进行某种测试来验证这一点；否则有一天，您会在愤怒的寻呼机中醒来，因为他们丢失了数百万美元的交易，或者更糟糕的是有关丢失或暴露数据的诉讼。另一方面，您只想选择最重要的东西以这种方式进行测试，因为这样做既昂贵又耗时。

2. 接受可变输入

   另一种方法是让您的第二个程序接受尽可能多的输入，并正确处理它们。您可以对此进行单元测试。将流程 B 设计为尽可能容错，并为您希望处理的尽可能多的故障案例编写测试。如果它应该处理foo并将其转换为bar，它应该如何处理FoO？还是f o o？如果它根本没有收到任何输入，它应该如何响应？这种容错是loose coupling的一种。

   一般来说，快速而艰难地失败是可取的（即接受一组固定的输入，并在遇到意外情况时引发明确的异常）。但是当您不能可靠地定义这些输入时，您必须处理所有请求而不会失败。例如，如果你是一个用户可见的网络服务器，你不能希望测试所有的输入，所以你必须处理任何可能被你扔掉的东西。

根据您的需要，您可能希望更多地依赖选项 1 或选项 2。如果没有更多上下文，很难说您应该以哪种方式倾斜多少，但希望这足以让您思考它。

Answer 3

如果您还没有准备好采用集成测试，那么权宜之计就是使用数据驱动的单元测试。有很多方法可以完成这项工作；当我读到这个问题时，让我印象深刻的是：

1. 为每个流程使用单独的测试输入和测试验证文件，然后
2. 使用进程 A 的测试验证文件作为进程 B 的测试输入文件

所以当您更新流程 A 的验证文件时，您对流程 B 的测试将立即失败，提醒您更新流程 B 的验证文件。当然，当您更新流程 B 的测试输入文件时，进程 A 的测试将立即失败，提醒您更新进程 A 的测试。