如何解决如何测试主要使用外部API的代码?
我最近写了一些代码,发现几乎不可能编写有用的测试。
这是一个cronjob,可以这样做:
- 通过外部服务(AWS cognito)获取用户
- 通过询问我们系统的内部API来检查用户的某些属性
- 根据业务逻辑发送用户邮件(AWS SES)
- 更新用户属性(AWS认知)
总共约有100行python。为了对此进行测试,通常的建议似乎是检查API的格式并在测试中模拟它们。我可以为自己的“幸福之路”做这件事,但是由于涉及到太多外部服务,我真的没有办法知道在所有情况和故障模式下如何传输数据。
如果收到一些意外的数据,我会期望这段代码失败,但是没有办法对此进行测试,或者存在吗?
我已经在较大的系统中使用契约进行了消费者驱动的合同测试,但是在这里我只能将其用于我们控制下的内部API,而对于如此小的应用来说,这样做所必需的基础设施似乎太多了脚本。
我们当前的方法是监视脚本中的错误并在第二天在办公室修复它。从业务规则的角度来看,如果脚本几天不运行就不是问题。您认为这是最好的方法吗?
您将如何测试?
解决方法
tldr;根据资源,优先级和关键性解决方案以及监视和一些单元测试可能是一个很好的选择。
在这种情况下,我将尝试分离组件。这将使我能够独立测试所有组件并简化最终测试逻辑。
让我们从示例中考虑cronjob。伪代码可能类似于下一个:
def main():
users: List[Users] = fetch_users()
filtered_users = check_properties(users)
business_logic_with_sending_emails(filtered_users)
update_properties(filtered_users)
我在单独的功能上划分了逻辑,现在我可以分别测试每个功能(甚至是主功能)
fetch_users
负责与外部系统进行交互并将其响应转换为预定义的用户模型。如果发生任何错误,fetch_users
应该处理。根据外部系统的不同,我可以使用集成测试或使用模拟/存根的单元测试来测试此功能。每个选项都有其优点和缺点。您提到监视和功能并不是关键,因此具有模拟/存根和监视的单元测试将是一个很好的选择。即使我们错过了模拟测试中的某些负面情况并且在生产中失败了,监视也可以捕获它,使用单独的fetch_users
函数,我们可以对其进行本地化和重现,然后可以轻松地用这种新情况扩展测试。
使用check_properties
,我们可以做同样的事情–使用完整测试或模拟/存根对其进行测试。这里的主要事情是我们不需要调用fetch_users
,我们可以将测试用户直接转移到check_properties
。正如您提到的check_properties
调用内部api一样,因此我们可以在此使用消费者驱动的合约测试(如果已经存在),或者使用完整测试或其他任何可以保证系统之间合约的测试(即通过swagger / openapi规范进行的验证) )
business_logic_with_sending_emails
—从业务角度来看,此功能可能是最重要的,因此我们需要使用单元(func)测试覆盖所有业务逻辑。幸运的是,我们不需要向任何实际的外部系统发出请求(获取用户),只需将测试用户直接转移到business_logic_with_sending_emails
。我们甚至不需要检查真实的电子邮件发送,足以检查我们是否调用了发送电子邮件的功能(发送真实的电子邮件,我们可以在单独的集成测试中检查)
使用update_properties
与fetch_users
具有相同的故事。
最后一个是main
。虽然我们分别测试了所有功能,但并不能保证main中的所有功能均已正确调用。可能在如示例伪代码这样的简单函数中,不需要对其进行测试(因为没有任何复杂的逻辑),但是在复杂的情况下,最好检查“幸福的道路”,并且很少要否定的。可以通过模拟或IoC / DI机制来完成。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。