测试BDD中的副作用

Question

我有一个具有以下逻辑的API：

1. 从卡夫卡消费。
2. 处理记录。
3. 如果处理成功，则更新数据库。
4. 如果处理失败，则将其推送到Kafka主题。
5. 如果推送至Kafka主题失败，请提交。
6. 如果记录已成功处理，则提交。
7. 如果提交失败，则记录并继续使用下一个事件。

我正在为此API编写BDD。目前，我感觉我正在测试太多方案：

1. ProcessingFailed->数据库未更改->事件应推送到Kafka->应提交。
2. 卡夫卡推送失败->应该提交。
3. 提交失败->（怎么办？我应该检查日志是否正确打印吗？）
4. 快乐的路径->更新的数据库-> Kafka主题不包含事件->提交成功。

我的问题是，测试这种副作用的正确方法是什么？

现在假设我的处理步骤由三个步骤组成：

1. 从数据库中获取。
2. 进行HTTP调用。

现在假设我通过关闭数据库来模拟“处理失败”。现在我还需要测试未进行HTTP调用吗？

Answer 1

bdd测试的一个很好的通用规则是每个测试应该只有一个失败的原因。对于黄瓜，在每种情况下这仅转换为一个Then步骤。

以此为指导，我建议在流程的每个步骤中编写一个方案。

# Consume from Kafka
Given a certain thing has happened
# Process the record
When some action is performed successfully
# Update database if processed successfully
Then some result exists in the database

然后您的下一个场景从第一个场景停止的地方开始：

Given a certain thing happened
When the action is performed unsuccessfully
# Push failed message to Kafka queue
Then a failed message is sent

第三个场景在第二个场景离开的地方拾取：

Given a certain thing happened
And the action was performed unsuccessfully
When a failure message is sent
Then a thing should not exist in the database

每个方案都建立在先前方案中已验证的步骤之上，请小心确保方案不共享数据，或者取决于先前执行的方案是否成功。

Answer 2

  

目前，我感觉我正在测试太多场景   我的问题是，测试这种副作用的正确方法是什么？

好吧，这听起来像是您在描述状态机；转换是由协议中不同效果的表示驱动的。

鉴于此，我通常希望看到针对每个目标状态的测试。

根据对风险的评估，可能有必要对许多不同的方面进行自动检查-许多解耦的测试会探索状态机本身的不同情况，有些检查会确保编排不同效果的方法是正确的，请进行一些测试，以确保在将所有部件连接在一起时，整个部件都可以正常工作。

  

现在我还需要测试未进行HTTP调用吗？

这里可能有两个重要的问题要问自己：

1. 不进行自动化测试会有什么风险？
2. 为什么只添加测试就毫不费力？

如果测试对象“很简单，显然没有缺陷”，那么投资几率告诉我们，将时间和金钱用于额外的测试不是一个好方法。

另一方面，如果您正在寻找一个借口而不进行测试，那么您可能希望对设计进行批判。如果您要在“已经工作”的模块中添加/更改代码，那么尤其是是真的。测试投资的一大收益来自定期对我们要更改的代码进行许多简单而准确的测试，因此不愿意为要更改的代码添加新的测试是一个大红旗[tm]，表明某些东西不符合要求计划。