组织功能文件的最佳方法是什么？

Question

我是Specflow和BDD的忠实粉丝.在各种项目中,它对我来说非常棒.

我还没有解决的一个挑战是以某种方式组织我的特征文件和场景,这使得它易于导航和探索.想象一年后,其他人想要来参加并了解该系统.从哪儿开始？什么是最重要的,什么不重要？功能之间有什么关系？系统是否处理特定方案？作者有没有想过这个问题？

任何人都可以分享一些专注于此的技巧,阅读或工具吗？

Answer 1

这个问题真的是关于个人偏好,但我的答案是如何使我的目录更容易理解.

通过我一直在研究的项目,我不得不考虑这样的问题.我知道后来,其他人会通过黄瓜目录查看更多或修复各种bug.

一般来说,我们采用了这种方法(我将以我们的CucumberJS结构为例):

project
|   features
|   |   elements
|   |   |   pages
|   |   |   |   home.js
|   |   |   |   index.js // grab all of the things in the pages directory
|   |   |   |   search.js
|   |   |   index.js // grab everything in elements directory and the index of pages
|   |   |   urls.js
|   |   |   test_customers.js
|   |   feature_files
|   |   |   home
|   |   |   |   homepage_links.feature
|   |   |   |   homepage_accessibility.feature
|   |   |   |   homepage_check_welsh_translation.feature
|   |   |   search
|   |   |   |   search.feature
|   |   |   |   search_security.feature
|   |   step_definitions
|   |   |   common // Won't go into this, but we have a library of reusable steps and functions in here for different projects that we can just port over from git
|   |   |   project
|   |   |   |   pages
|   |   |   |   |   search
|   |   |   |   |   |   search_steps.js
|   |   |   |   |   |   search_security_steps.js
|   |   |   |   |   home
|   |   |   |   |   |   home_steps.js
|   |   |   |   |   |   home_accessibility_steps.js
|   |   |   |   navigation_steps.js
|   |   |   |   login_steps.js
|   |   support
|   |   |   env.js // Timeouts
|   |   |   hooks.js // Setup/Teardown for scenarios
|   |   |   world.js // Setting up the drivers
|   reports
|   |   2017
|   |   |   03
|   |   |   |   05
|   |   |   |   |   report.html
|   |   |   |   |   report.js
|   |   |   |   06
|   |   |   |   |   report.html
|   |   |   |   |   report.js
|   |   |   |   07
|   |   |   |   |   report.html
|   |   |   |   |   report.js
|   |   report.json
|   screenshots
|   |   failed
|   |   |   2017-03-05
|   |   |   |   search_security_xss_204057.png
|   |   |   2017-03-06
|   |   |   |   search_security_xss_100532.png
|   |   |   |   search_security_xss_101054.png
|   |   |   |   search_security_xss_101615.png
|   |   search_security
|   |   |   2017-03-06
|   |   |   |   search_security_xss_100528.png
|   |   |   |   search_security_xss_101050.png
|   |   |   |   search_security_xss_101611.png
|   |   |   |   search_security_xss_101841.png
|   .gitignore
|   README.md         

假设您是项目的新手,因此您想了解已编写的方案.你知道它是功能集的一部分,所以你沿着那条路走下去,你正在寻找功能文件,所以你沿着这条路走下去.您对如何针对搜索功能测试安全性感兴趣,因此您可以访问该文件并找到该文件.

在我们的文件夹结构的其余部分中,它是相同的理论.一切都正是你所期望的.

Answer 2

这是一个很大的问题，我认为我没有直接的答案，但这里有一些帮助我们塑造功能文件的注意事项。这很大程度上取决于项目的偏好和特定需求。

功能文件与用户故事不同。

从这个优秀的文章由马特·韦恩（黄瓜书的作者）：

当 Aslak 创建 Cucumber 时，他将文件从 .story 重命名为 .feature。这不是意外，也不是随意的奇思妙想：这是因为存在差异。

用户故事是一种规划工具。它们存在直到被实现，然后消失，被代码吸收。

Cucumber 功能是一种交流工具。它们描述了系统今天的行为方式，因此如果您需要检查它是如何工作的，您无需阅读代码或在实时系统上按下按钮。根据计划和实施的方式组织您的功能会分散您的注意力。

编写使用业务语言密集的声明性功能文件可能会使您的场景比完美的目录结构更容易被发现

随着项目的增长（越来越多的人开始贡献），直接浏览到场景的位置变得越来越困难。下一个最好的事情？正在寻找它。如果您的场景更具声明性且不那么必要，这会更容易。从这篇文章从SauceLabs：

测试应该主要关注需要完成什么，而不是如何完成的细节。当非开发人员阅读它们时，它们大多应该是可以理解的。

以更高抽象级别编写的紧凑场景的好处在于，您可以在功能文件开始变得拥挤之前将更多场景放入功能文件中。对于系统测试，我们很幸运地将高级小黄瓜与页面对象模式配对，因为它为所有细节提供了一个层。

如果使用与 UI 相同的业务语言，则更容易找到场景和功能

如果您在 UI 中有一个名为“删除”的操作，在测试中有一个名为“删除”的操作，在生产代码中有一个名为“存档”的操作，那么开发人员或业务人员可能很难找到与该操作相关联的场景。如果测试始终遵循 UI（假设使用 BDD 工具的普通团队成员比源代码更熟悉 UI），那么搜索场景可能会更容易。