我应该在我的情况下编写什么样的测试？

Question

我对单元测试、功能测试等有点陌生。

对于我的案例的最佳方法，我有点困惑：

我的服务是这样做的：

1. 通过 SFTP 连接到远程服务器
2. 在本地复制一些 XML 文件
3. 解析这些文件
4. 将解析后的数据保存到数据库中

我的服务运行良好，但我的问题是：如何测试这种行为？

Answer 1

专注于测试代码中最具风险的元素。我所说的“风险元素”是指可能实施不正确或不完整的事情，或者在您进行其他更改时可能会中断。

判断您应该测试什么的一种简单方法是您经常点击“刷新”或“编译”的部分，以查看会发生什么以及您是否已完成。例如，您提到您的系统解析 XML 文件：您可能想要各种输入 XML 文件以确保它们都能正常工作，但如果某个完美的人将 XML 解析代码交给您并说“这保证可以工作”，您可能不会用手锻炼或探索。 自动化测试可以让你成为完美的人，或者至少知道你的代码什么时候很有可能工作。此外，如果您发现该系统无法运行的情况，它允许您编写测试以确定您的系统何时可以正常工作，并确保您的更改不会导致系统在您之前编写的任何测试中都失败了。

到那时，您将成为系统中哪些部分风险最大的最佳专家，因此您可以最好地编写测试来降低风险。您可能还需要重组代码以使其足够灵活以进行测试，这可能包括使字段和方法可见或允许在数据库处理代码中使用替代数据库连接；如果它使您的系统更易于测试，这是正常且有价值的。

---

单元测试适用于小型且独立的系统，这意味着它们不一定适用于堆栈中的所有部分：

1. 通过 SFTP 连接到远程服务器

这部分可能很难进行单元测试，因为如果您的计算机离线或 SFTP 服务器已关闭，您不一定希望测试失败。编写功能测试或集成测试以确保您的系统继续与您想要的 SFTP 服务器一起工作可能是个好主意。

如果您想检查您的系统是否正确解释您的配置以向正确的 SFTP 服务器发出正确的请求，这可能是一个很好的测试单元，但只能保证您是提出正确的请求，而不是给您正确的响应或行为。对于mock framework（模拟您的 FTP 调用）来说，这可能是一个很好的案例，但这也存在同样的问题：您可以验证您正在发出预期的请求，但不能验证是否有正确的响应来自它。

1. 在本地复制一些 XML 文件

在单元测试中使用文件系统可能很困难，因为您需要确保将文件设置在临时目录或其他不受实际数据或先前测试影响的可预测位置。但是，可以这样做：您可以创建一个示例 XML 文件，运行您的复制代码，并验证结果是否在预期的位置。

再一次，您可以使用模拟或存根来验证您对文件系统的调用是否正确，这可能比使用真正的文件系统更可预测，但只能保证您正在进行预期的调用，而不是你得到了正确的结果。

1. 解析这些文件

这是一个非常简单的单元测试案例。准备或下载一些示例文件，通过解析器运行它们，并确保输出符合您的预期。

4. 将解析后的数据保存到数据库中

这部分也很容易测试，如果很费力：您可以获取已解析的示例数据，将其发送到您的系统，然后读取数据库以确保其中的片段如您所愿。这里的困难可能在于确保您的数据库设置类似于生产但不使用真正的生产数据库；你可能想使用内存数据库。

同样，您可以选择简单地检查数据库命令是否准确：您可以决定确保使用正确的查询和正确的参数就足够了。但是，使用真正的数据库引擎将为您提供更彻底的测试，确保命令成功，它通过任何有关所需字段或格式的数据库验证规则，并且它不会截断或丢弃字符或数字精度。

集成测试可以确保，对于给定的 XML 文件，它可以正确地到达数据库；然而，这样的测试可能会更慢，如果它失败了，你可能需要做更多的工作来确定哪个单元失败了。因此，您可能应该尽快考虑全面的单元测试，然后再专注于集成和端到端测试。

另请参阅：Are (database) integration tests bad?，这是我在 Software Engineering Stack Exchange 上回答的一个相关问题