组织功能文件的最佳方式是什么？ [关闭]

Question

我尚未解决的一个挑战是以某种方式组织我的功能文件和场景，以便在 Specflow 和 BDD 中轻松导航和探索。

想象一年后有人想来了解这个系统。从哪儿开始？什么最重要，什么不重要？特征之间有什么关系吗？系统是否处理特定场景？作者有没有想过这个问题？

谁能分享一些专注于此的技术、阅读或工具？

Answer 1

这个问题确实是关于个人喜好，但我的答案是如何让我的目录更易于理解。

对于我一直从事的项目，我不得不考虑很多类似的问题。我知道以后，其他人会查看 cucumber 目录以添加更多内容或进行各种错误修复。

一般来说，我们采用了这种方式（我以我们的 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

我的方法是按用户类型对端点上的操作进行组织：应用程序/页面，因为从根本上说，测试是检查每个 RESTful API 如何由谁在何时何地调用什么。

就个人而言，我也喜欢 Robot Framework 而不是 Cucumber。

Answer 3

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

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

来自 this excellent article 来自 Matt Wynne（The Cucumber Book 的作者）：

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

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

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

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

随着项目的增长（以及越来越多的人开始贡献），直接浏览到场景的位置变得越来越困难。下一个最好的事情？正在寻找它。如果您的场景更具声明性且命令较少，这会更容易。来自this article from SauceLabs：

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

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

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

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