当我进入这个项目时,在“功能/增强”中进行了黄瓜测试,其中使用了javascript和一些不需要js的“features / plain”。随着后期开发的每个场景@javascript,这没有意义。随着我们增长和增长的功能文件的数量,如果这保持整洁,它会很棒。
所以,在最佳实践中:
1).feature文件需要多长时间?我尝试用1或2个“场景”保持每个狭窄和具体。
2)应该保留哪些文件夹/文件结构? 2a)一组有多相似的特征?
答案 0 :(得分:2)
1)一旦你完成它们几个月,你很快就会找到最适合你的东西。我的建议是你应该让它们变小。我们经常将早期的功能拆分为较小的块,但从未结合它们。这对于利用背景等很方便......
2)我们遇到了一个很大的问题,花了很多年的时间来做另一种方式。最后,我们开始根据我们公司提供的服务对它们进行分组。例如付款,客户注册,库存管理
不方便的是,功能并不总是符合世界的分层树视图,因此自由使用标记和主要的功能分组并不那么重要。
你试过院子吗?有一个例子here我们刚刚将它构建到我们的CI中,它可以让你根据标签将各种场景组合起来,你可以做联合,交叉等等......非常值得:)答案 1 :(得分:1)
我会将场景的JavaScript和非JavaScript版本保持在一起,因为它们应该非常相似。
功能文件中超过8个场景的任何内容可能都太多了。
一种有用的方法是使用一个文件夹来表示高级功能(有时称为史诗或主题),并在这些文件夹中为行为的不同方面分隔功能文件。
例如,您可能有一个功能“员工目录”,其中包含单独的功能文件,其中包含照片,办公地点,职位等方案。
根据应用的大小和复杂程度,您可以将这些文件夹分组到其他文件夹中。
(请注意,上述内容均不适用于Rails应用程序。)