BDD 命名：什么时候不再关注用户体验？
我被 MSpec 所吸引，希望有一天能与非开发人员分享我的测试报告< code>*，但如果我在测试/场景名称（而不是实际测试中的各个 C# 对象/成员）中讨论业务（用户体验），那么这是最有价值的（对吗？）。
但我正在努力利用我的低级功能在我的测试/场景名称中引用非开发人员的担忧。关注点离 UI 越远，命名场景就越困难，以便 a) 与非开发人员相关，b) 描述正在测试的低级功能。
当您距离 UI 越来越远时，是否存在无法与非开发人员共享测试/场景名称的情况？我觉得答案应该是“否”，因为我不应该测试行为，除非它是非开发人员关心的事情，但我经常失败，以至于我不确定是什么我失踪了。
如果某处有明显的答案，我将不胜感激一些引用/参考文献。
* 例如最终用户或其他利益相关者（“利益相关者”可能包括未来的开发人员 - 或者一年半后的我 - 使用这些规范来深入了解< em>系统的原因）
I'm drawn to MSpec with the hopes of one day sharing my test reports with non-developers*, but that is most valuable (right?) if I discuss the business (the user experience) in the test/scenario names (instead of the individual C# objects/members actually under test).
But I'm struggling, with my low-level functionality, to cite non-developer concerns in my test/scenario names. The farther the concern is from the UI, the more difficulty in naming the scenario such that it both a) is relevant to the non-developer and b) describes the low-level functionality being tested.
As you move farther and farther from the UI, is there a point at which test/scenario names just can't be shared with non-developers? I feel like the answer should be "no", because I shouldn't be testing behavior unless it's something the non-developer cares about, but I'm failing regularly enough that I'm not sure what I'm missing.
If there are obvious answers somewhere, I'd appreciate some citations/references.
* e.g. end users or other stakeholders ("stakeholders" might include future developers -- or me in a year and a half -- using these specifications to gain insight into the why of the system)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们通常使用“场景”一词来描述全系统、用户 POV 场景。
如果您想要一个词来描述类级别的行为，请尝试“示例”。
您的示例将来自您班级用户的观点。如果这些用户类想要特别以开发人员为中心的行为，那么，是的，您的示例最终将出现以开发人员为中心的问题。
话虽如此，这里有一些我发现的词汇变化，让我以最面向商业的方式表达我正在寻找的价值：
，请想象用更多的单词向某人解释它，然后使用它。
不过，我不会太过分。在场景中使用涉众领域特定术语的原因是因为涉众有兴趣阅读和（希望）编写它们。班级级示例的受众是技术人员，因此如果我们对其中有技术问题也没有多大关系。
We normally use the word "scenario" to describe full-system, user-POV scenarios.
If you would like a word to describe class-level behaviour, try "example".
Your examples will be from the points of view of the users of your class. If those user classes want particularly developer-centric behaviour, then, yes, your examples will end up with developer-centric concerns in them.
Having said that, here are some vocabulary changes which I've found let me phrase the value I'm looking for in the most business-oriented way I can:
Basically, if you're using a developer-jargon word, imagine explaining it to someone in a few more words, then use that.
I wouldn't go overboard with it, though. The reason for using the stakeholders' domain specific terms in scenarios is because stakeholders are interested in reading and (hopefully) writing them. The audience for the class-level examples is technical, so it doesn't matter so much if we have technical concerns in them.