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

前端之家收集整理的这篇文章主要介绍了单元测试 – 在测试该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“后门”或者可能需要进行一些手动验证(所有测试都需要自动化吗?).

原文链接:https://www.f2er.com/javaschema/281673.html

猜你在找的设计模式相关文章