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