我还没有解决的一个挑战是如何以一种易于在Specflow和BDD中导航和探索的方式组织我的特性文件和场景。
想象一年后有人想要学习这个系统。应该从哪里开始？什么是最重要的，什么是不太重要的？特性之间是否存在关系？系统是否处理了特定的场景？作者是否考虑过这个问题？
有没有人可以分享一些专注于这方面的技术、读物或工具？
3个回答
15
这个问题实际上涉及到个人偏好，但我的答案是如何让我的目录更易于理解。
在我一直从事的项目中，我不得不思考这样的问题。我知道，在后面的日子里，其他人会浏览黄瓜目录以添加更多内容或进行各种错误修复。
一般来说，我们采取了这种方法（我将使用我们的CucumberJS结构作为例子）：
在我一直从事的项目中，我不得不思考这样的问题。我知道，在后面的日子里，其他人会浏览黄瓜目录以添加更多内容或进行各种错误修复。
一般来说，我们采取了这种方法（我将使用我们的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
假设你是一个新项目的成员，想要了解已经编写了哪些场景。你知道这是特性集的一部分，所以你选择该路线，找到对应的特性文件。你对搜索功能的安全性测试很感兴趣，因此你进入其中并找到了相关文件。
我们的文件夹结构中都遵循同样的理论，每个文件都会被放置在你预期的位置。
- KyleFairns
3
6
这是一个很大的问题，我认为我没有直接的答案，但这里有一些考虑因素可以帮助我们塑造特性文件。很多时候这取决于个人喜好和项目的具体需求。
特性文件与用户故事并不相同。如Matt Wynne（《Cucumber Book》的作者）在这篇优秀的文章中所述：
当Aslak创建Cucumber时，他将文件从.story更名为.feature。这不是意外或任意的行为：这是因为存在差异。用户故事是一种规划工具。它们存在直到被实施，然后消失并吸收到代码中。Cucumber特性是一种沟通工具。它们描述了系统今天的行为，所以如果您需要检查它如何工作，您不需要阅读代码或在现场系统上按按钮。根据计划和实施方式组织您的特性会分散注意力。 编写使用业务语言密集的声明性特性文件可能会使您的场景比完美的目录结构更易发现。当您的项目增长（并且越来越多的人开始贡献）时，直接浏览到场景位置变得越来越困难。下一个最好的选择？搜索它。如果您的场景更具声明性而不是命令式，这会更容易。来自SauceLabs这篇文章：
测试应主要关注需要完成的内容，而不是如何完成它们的细节。非开发人员读取时应该基本上可以理解。
高抽象级别编写的紧凑场景的好处在于，在文件开始感觉拥挤之前，您可以将更多场景放入其中。对于系统测试，我们使用高级gherkin和页面对象模式进行配对，因为它提供了所有细节层的层次结构。
使用与UI相同的业务语言编写的场景和特性更易于查找。如果您的UI中有一个名为“删除”的操作，在测试中为“删除”，在生产代码中为“存档”，则可能很难找到与该操作相关联的场景，如果测试始终遵循UI（假设使用您的BDD工具的平均团队成员比源代码更熟悉UI），则搜索场景可能更容易。
当Aslak创建Cucumber时，他将文件从.story更名为.feature。这不是意外或任意的行为：这是因为存在差异。用户故事是一种规划工具。它们存在直到被实施，然后消失并吸收到代码中。Cucumber特性是一种沟通工具。它们描述了系统今天的行为，所以如果您需要检查它如何工作，您不需要阅读代码或在现场系统上按按钮。根据计划和实施方式组织您的特性会分散注意力。 编写使用业务语言密集的声明性特性文件可能会使您的场景比完美的目录结构更易发现。当您的项目增长（并且越来越多的人开始贡献）时，直接浏览到场景位置变得越来越困难。下一个最好的选择？搜索它。如果您的场景更具声明性而不是命令式，这会更容易。来自SauceLabs这篇文章：
测试应主要关注需要完成的内容，而不是如何完成它们的细节。非开发人员读取时应该基本上可以理解。
高抽象级别编写的紧凑场景的好处在于，在文件开始感觉拥挤之前，您可以将更多场景放入其中。对于系统测试，我们使用高级gherkin和页面对象模式进行配对，因为它提供了所有细节层的层次结构。
使用与UI相同的业务语言编写的场景和特性更易于查找。如果您的UI中有一个名为“删除”的操作，在测试中为“删除”，在生产代码中为“存档”，则可能很难找到与该操作相关联的场景，如果测试始终遵循UI（假设使用您的BDD工具的平均团队成员比源代码更熟悉UI），则搜索场景可能更容易。
- Nathaniel C
1
2尽可能详细地描述始终是一个好的起点，并且在长期来看将百分之百有所帮助。使用页面对象模型或剧本模式是实现这一目标的绝佳方式，而且非常容易。话虽如此，良好的文件夹结构作为基础也是帮助新手探索框架或调试破损测试的可靠方法，特别是如果您没有使用具有单击方法以打开其源代码功能的IDE。 - KyleFairns
-2
我的方法是按照用户类型对终点操作进行组织：应用程序/页面，因为从根本上讲，测试的目的是检查每个RESTful API由谁在何时何地调用。
个人而言，我更喜欢Robot Framework而不是Cucumber。
- Yuan-Hsun Tang
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接
homepage_check_welsh_translation.feature，但没有威尔士语翻译步骤。这在实践中经常发生。我在home_steps.js中编写的步骤 - 在这种情况下将适用于威尔士语翻译，但由于它们在技术上是两个不同的功能，我会将功能文件分开。如果我想要添加一个仅用于威尔士语翻译的新步骤，那么我会创建一个新的步骤文件。 - KyleFairns