naming - BDD 命名 : when does it stop being about the user experience?

Question

我被吸引到 MSpec希望有一天能与非开发人员分享我的测试报告 * ，但如果我在测试/场景名称(而不是实际测试中的单个 C# 对象/成员)中讨论业务(用户体验)，这是最有值(value)的(对吗？)。

但是我正在努力用我的低级功能在我的测试/场景名称中引用非开发人员的问题。关注点离 UI 越远，命名场景就越困难，以便 a) 与非开发人员相关，b) 描述正在测试的低级功能。

随着您离 UI 越来越远，是否存在无法与非开发人员共享测试/场景名称的问题？我觉得答案应该是“不”，因为我不应该测试行为，除非它是非开发人员关心的事情，但我经常失败，以至于我不确定我错过了什么。

如果某处有明显的答案，我会很感激一些引文/引用文献。
*例如最终用户或其他利益相关者(“利益相关者”可能包括 future 的开发人员——或者一年半后的我——使用这些规范来深入了解系统的原因)

Answer 1

我们通常使用“场景”一词来描述全系统、用户 POV 场景。

如果您想用一个词来描述类级别的行为，请尝试“示例”。

您的示例将来自您类(class)用户的观点。如果这些用户类想要特别以开发人员为中心的行为，那么，是的，您的示例最终会以开发人员为中心。

话虽如此，以下是我发现的一些词汇变化，让我以最面向业务的方式表达我正在寻找的值(value):

返回 -> 告诉我或给我

调用 -> 代表，询问

处理并发 -> 一次处理两件事

扩展 -> 是

实现 -> 执行

的角色

基本上，如果您使用的是开发人员行话，想象一下用更多的词向某人解释它，然后使用它。

不过，我不会过度使用它。在场景中使用涉众领域特定术语的原因是涉众有兴趣阅读和(希望)编写它们。类级别示例的受众是技术性的，因此我们是否在其中有技术问题并不重要。