在测试该API的包装器时,我的单元测试是否应该直接触摸API？

我有一些编写了一些测试围绕FTP服务器API的包装器的单元测试.

单元测试和FTP服务器都在同一台机器上.

包装器API部署到我们的平台,并用于远程处理和Web服务方案.包装器API本质上使用XML消息来执行诸如添加/删除/更新用户,更改密码,修改权限等任务.

在单元测试中,比如说要将用户添加到虚拟域,我创建XML消息以发送到API.API执行它并返回一个响应,其中包含有关操作是成功还是失败的状态信息(错误代码,验证失败等).

要验证API包装器代码是否确实做了正确的事情(如果响应指示成功),我调用FTP服务器的COM API并直接查询其商店以查看,例如,在创建用户帐户时,用户帐户是否确实得到了.

这味道不好吗？

更新1: @ Jeremy/Nick:包装器是测试的重点,FTP服务器及其COM API是第三方产品,可能经过良好测试和稳定.包装器API必须解析XML消息,然后调用FTP服务器的API.我如何验证,这可能是一个愚蠢的情况,包装器正确设置了用户帐户的特定属性.例如,由于包装器代码中的拼写错误而设置了FTP帐户的错误属性或属性.一个很好的例子是设置上传和下载速度限制,这些可能会在包装器代码中转换.

更新2:感谢大家的答案.对于那些建议使用模拟的人来说,它已经超出了我的想法,但光线还没有在那里开启,我仍然在努力让我的头脑如何让我的包装器与模拟FTP服务器一起工作.模拟驻留在哪里,我是否将所述模拟的实例传递给包装器API而不是调用COM API？我知道嘲笑但是很难理解它,主要是因为我发现大多数的例子和教程都是如此抽象而且(我很惭愧地说)接近难以理解.

您似乎在混合单元和组件测试问题.

如果您对包装器进行单元测试,则应使用模拟FTP服务器,而不涉及实际的服务器.好的一面是,你通常可以实现这样的100%自动化.

如果您正在对整个事物(包装器+ FTP服务器一起工作)进行组件测试,请尝试在与测试相同的级别验证结果,即通过包装器API.例如,如果发出上载文件的命令,则发出命令以删除/下载该文件以确保文件已正确上载.对于更复杂的操作,测试结果并不容易,那么请考虑使用您提到的COM API"后门"或者可能需要进行一些手动验证(所有测试都需要自动化吗？).