我们最近开始使用 Cucumber 练习 BDD，几个月后 - 我们可以清楚地看出我们的致命弱点是编写可维护的功能文件。例如：
一些团队编写了非常技术性的功能文件，其中包含有关内部实现的信息。这使得大多数非技术人员无法阅读该功能文件。另一个例子是，一些团队编写了非常通用的特征文件——考虑尽可能少地定义步骤以保持其干燥——但随着时间的推移，他们认为当你限制自己时很难有一个可读的特征文件整个项目的少量步骤定义。
互联网上有一些关于如何正确编写特征文件的提示，但这些提示是有限的，并且对于特定示例很有用。是否有任何网站，或者一本好书，可以分享一些最佳实践？从多年经验中总结出的一些做法？
【问题讨论】：
您一直在努力寻找有关该主题的明确文本的原因是，据我所知，还没有。一旦你开始并理解了 BDD 的要点，那么困难的部分就是找出适合你的方法。有一些非常好的书籍可以帮助您更成功地做到这一点 - 例如 Specification By Example，但它并不是一种万能的解决方案。
就如何在技术上编写您的场景而言，这取决于他们的受众。如果使用 BDD 的好处之一是所有相关的利益相关者都可以在开发之前讨论特性，那么在每个人都可以访问的级别上编写它们是其中必要的一部分。也就是说，没有任何理由走得太远。如果每个人都能做出贡献，那为什么还要努力降低技术含量？
就可维护性而言，抽象是关键。以网站的 BDD 为例，这是我最有经验的，最重要的实现方式是使用页面对象或包装器在步骤定义和正在测试的对象之间实现抽象层。通过这样做，您可以拥有许多几乎相同的步骤定义，它们使用您的包装器略有不同，但就可维护性而言，其中绝大多数将通过对您的页面对象进行小的更改来实现，这些更改会传播到您的自动化的其余部分套房。
多年来我尝试了几种不同的方法，这就是我的工作方式。我不认为有很多步骤定义会使代码不那么 DRY，只要它们实现了一个包装器，就不会有太多重复的代码。
编辑：在 cmets 中回答您的问题...
真的只有一种方法，我看到的所有变化都与工具有关。您使用的工具（如果您选择使用任何工具）将取决于被测系统。唯一真正重要的想法是为处理获取、设置和与测试对象交互的屏幕的每个页面/屏幕/区域设置一个包装器。然后您的步骤定义包含所有实际逻辑。例如处理你的断言或你想调用什么页面对象方法来模拟用户会做什么。
【讨论】：