我是单元测试，功能测试等的新手。
对于适用于我的案例的最佳方法，我有些困惑：
我的服务这样做：
我的服务运行正常，但我的问题是：如何测试这种行为？
答案 0 :(得分：0)
专注于测试代码中最具风险的元素。所谓“危险的元素”，是指可能被错误或不完全地实现的事情，或者可能在以后进行其他更改时会破坏的事情。
一种简单的方法来告诉您应该测试什么，就是您经常单击“刷新”或“编译”的部分，以查看会发生什么以及是否完成。例如，您提到您的系统解析XML文件：您可能想要各种各样的输入XML文件以确保它们都能正常工作，但是如果某个完美的人将XML解析代码交给您并说“保证可以正常工作”，可能不会手工锻炼或探索。 自动测试使您成为完美的人，或者至少知道什么时候您的代码很有可能起作用。此外，如果您发现该系统无法运行的情况，则可以让您编写测试以确定该系统何时在该情况下运行，并确保所做的更改不会引起您先前编写的任何测试都使系统失败。
到那时，您将是系统上风险最高的最佳专家，因此您可以最好地编写测试来减轻这种风险。您可能还需要重组代码，使其具有足够的灵活性以进行测试，其中可能包括使字段和方法可见，或者在数据库处理代码中允许使用替代数据库连接。如果它使您的系统更具可测试性，那么这是正常且有价值的。
单元测试适用于小型且独立的系统，这意味着它们不一定适合堆栈中的所有组件：
- 通过SFTP连接到远程服务器
这部分可能很难进行单元测试，因为如果您的计算机离线或SFTP服务器关闭，您不一定希望测试失败。编写功能测试或集成测试以确保您的系统继续与所需的SFTP服务器一起使用可能是个好主意。
如果您要检查系统是否正确解释了配置，以向正确的SFTP服务器发出正确的请求，这可能是一个很好的测试单位，但只能保证您做出正确的请求，而不是给您正确的响应或行为。对于mock framework（嘲笑您的FTP调用），这可能是一个很好的例子，但是也遇到了同样的问题：您可以验证自己发出的是预期的请求，但不是正确的响应。
- 在本地复制一些XML文件
在单元测试中使用文件系统可能很困难，因为您需要确保将文件设置在不会受到实际数据或先前测试影响的临时目录或其他可预测的位置。但是，可以这样做：您可以创建一个示例XML文件，运行复制代码，并验证结果是否在预期的位置。
再次，您可以使用模拟或存根来验证对文件系统的正确调用，这可能比使用真实文件系统更可预测，但仅保证您进行了预期的调用，而不是您得到正确的结果。
- 解析这些文件
这是一个非常简单的单元测试案例。准备或下载一些示例文件，通过解析器运行它们，并确保输出符合您的期望。
- 将已解析的数据保存在数据库中
如果费力的话，这部分也很容易测试：您可以获取已解析的示例数据，将其发送到您的系统，然后读取数据库以确保数据片段如您所愿。这里的困难可能在于确保您的数据库的设置与生产类似，但不使用实际的生产数据库。您可能要使用内存数据库。
同样，您可以选择简单地检查数据库命令是否正确：您可以确定足以确保使用具有正确参数的正确查询。但是，使用真实的数据库引擎将给您进行更彻底的测试，确保命令成功，通过了有关必填字段或格式的任何数据库验证规则，并且不会截断或删除字符或数字精度。 / p>
集成测试可以确保对于给定的XML文件，它正确地一直贯穿数据库。但是，这样的测试可能会变慢，如果测试失败，则可能需要做更多的工作才能确定哪个单元发生了故障。因此，您可能应该尽快考虑进行全面的单元测试，并在以后集中精力进行集成和端到端测试。
另请参见： Are (database) integration tests bad?，这是我在软件工程堆栈交换上回答的一个相关问题