推荐阅读如何编写适当的功能文件

Question

我们最近开始用黄瓜练习BDD，经过几个月左右的时间 - 我们可以清楚地看出我们的致命弱点正在编写可维护的功能文件。例如：

一些团队编写了非常技术性的功能文件，其中包含有关内部实现的信息。这使得大多数非技术人员无法读取该功能文件。另一个例子是，一些团队编写了非常通用的特征文件 - 考虑尽可能少的步骤定义以保持干燥 - 但是随着时间的推移，他们认为当你限制自己时很难有一个可读的特征文件整个项目中的少量步骤定义。

互联网上提供了一些关于如何正确编写功能文件的提示，但这些提示有限，并且适用于特定示例。是否有任何网站，或许是一本好书，分享一些最佳实践？从多年的经验中收集到的一些做法？

Answer 1

你一直在努力寻找关于这个主题的明确文本的原因是，据我所知，没有一个。一旦开始并理解BDD的要点，那么困难的部分就是找出适合您的方法。有一些非常好的书可以帮助你更成功地做到这一点 - 比如规范示例，但它不是一个适合所有解决方案。

就技术如何编写场景而言，它取决于他们的受众。如果使用BDD的好处之一是所有相关的利益相关者都可以在开发之前讨论功能，那么在每个人都可以访问的级别上编写它们是必要的一部分。也就是说没有任何理由对它过分苛刻。如果每个人都能做出贡献那么为什么要更加努力地降低技术水平？

在可维护性方面，抽象是关键。以网站的BDD为例，就像我最熟悉的那样，实现这一目标最重要的方法是使用页面对象或包装器来实现步骤定义和正在测试的对象之间的抽象层。通过执行此操作，您可以使用几乎相同的步骤定义，使用您的包装器略有不同，但就可维护性而言，绝大多数步骤定义将通过对页面对象进行小的更改来实现，这些更改会通过其余的自动化传播套件。

这是我工作的方式，多年来尝试了几种不同的方法。我不认为有很多步骤定义会使代码更少干，因为只要它们实现了一个包装器，就不会重复代码。

编辑：在评论中回答你的问题......

真的只有一种方式，我所看到的所有变化都与工具有关。您使用的工具，如果您选择使用任何工具，将取决于被测系统。唯一非常重要的想法是为屏幕的每个页面/屏幕/区域设置一个包装器，用于处理获取，设置和与测试对象交互。然后您的步骤定义包含所有实际逻辑。例如处理你的断言或你想要调用的页面对象方法来模拟用户会做什么。