blocks|key|3063676|text|我们还开始使用Cucumber-JVM进行验收测试，在组织代码方面也遇到了类似的问题。我们为每个特征选择了1步定义类。目前这是很好的，因为我们正在测试的功能并不是非常复杂和完全独立的，我们的功能之间几乎没有重叠。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3063677|我认为您提到的第二种方法会更好，但将几个不同的步骤定义类绑定到一个场景中通常是具有挑战性的。我认为，一旦你开始添加更多的功能并像往常一样重构，最好的项目结构将变得更加清晰。|3063678|同时，这里有一个cucumber的Eclipse插件，|3063679|https://github.com/matthewpietal/Eclipse-Plugin-for-Cucumber|offset|length|3063680|在编写特性时，它具有语法突出显示以及现有可用步骤的列表。|3063681|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|1O|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|V|8|@]|9|@$H|W|I|X|1|Y]]|A|$]]|$1|J|3|K|5|6|7|Z|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|G]]]]

We have also started using Cucumber-JVM for acceptance testing and have similar problems with organising code. We have opted to have 1 step definition class for each feature. At the moment this is fine as the features we are testing aren't very complex and quite separate, there is very little overlap in our features.

The second approach you mentioned would be better I think, but it is often challenging to tie together several different step definition classes for a single scenario. I think the best project structure will become clearer once you start adding more features and refactor as normal.

In the meantime here is an Eclipse plugin for cucumber, 

<a href="https://github.com/matthewpietal/Eclipse-Plugin-for-Cucumber" rel="nofollow">https://github.com/matthewpietal/Eclipse-Plugin-for-Cucumber</a>

it has syntax highlighting as well as a list of existing available steps when writing a feature.

blocks|key|212192|text|我建议根据代码引用的对象对代码进行分组，类似于您在问题中提出的选项#2。原因是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|212193|212194|根据代码的使用方式和位置来组织代码是一个很大的禁忌。它实际上是在你的功能文件和你的代码之间创建耦合。|unordered-list-item|212195|212196|在您的产品代码中想象这样一件事--+SendEmail()函数不会在一个名为NewEmailScreenCommands的类中，对吗？它应该是在EmailActions或类似的语言中。|offset|length|style|CODE|212197|同样的道理也适用于这里；根据代码做什么来构造代码，而不是根据谁在使用它。|212198|第一种方法会使重新组织您的功能文件变得困难；无论何时更改您的功能文件，您都必须更改代码文件。|212199|
|212200|将代码按主题分组使DRYing更加容易；您确切地知道处理user实体的所有代码的位置，因此更容易重用它。|212201|212202|在我们的项目中，我们使用这种方法(即BlogPostStepDefinitions类)，如果类太大，则进一步将代码分离为步骤类型(即BlogPostGivenStepDefinitions)。|212203|entityMap^0|0|0|0|0|I|B|12|M|20|C|0|0|0|0|S|4|0|0|I|N|1U|S|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|11|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|13|8|@$I|14|J|15|K|L]|$I|16|J|17|K|L]|$I|18|J|19|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|1A|8|@]|9|@]|A|$]]|$1|O|3|P|5|E|7|1B|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1C|8|@]|9|@]|A|$]]|$1|S|3|T|5|E|7|1D|8|@$I|1E|J|1F|K|L]]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1H|8|@$I|1I|J|1J|K|L]|$I|1K|J|1L|K|L]]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]]|Y|$]]

I would suggest grouping your code according to the objects it refers to, similar to option #2 you presented in your question. The reasons being: 

<ul>
<li>Structuring your code based on how and where it's being used is a big no-no. It's actually creating coupling between your feature files and your code. 
Imagine such a thing in your product's code- the <code>SendEmail()</code> function wouldn't be in a class called <code>NewEmailScreenCommands</code>, would it? It would be in <code>EmailActions</code> or some such. 
So the same applies here; structure your code according to what it does, and not who uses it. </li>
<li>The first approach would make it difficult to re-organize your feature files; You'd have to change your code files whenever you change your feature files. </li>
<li>Keeping code grouped by theme makes DRYing it much easier; you know exactly where all the code dealing with the <code>user</code> entity is, so it's easier for you to reuse it. </li>
</ul>

On our project we use that approach (i.e <code>BlogPostStepDefinitions</code> class), with further separating the code, if the class gets too large, to types of steps (i.e <code>BlogPostGivenStepDefinitions</code>).

blocks|key|212205|text|在我目前参与的项目中，我们问了自己同样的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|212206|在摆弄了一些可能性之后，我们选择的是您公开的两种解决方案的混合。|212207|212208|将步骤重新分组为以主题为中心的通用步骤类|unordered-list-item|212209|app-start步骤|212210|安全检查步骤|212211|在此处放置随机要素关注|212212|212213|212214|​|212215|212216|和场景类(在某些情况下甚至是功能)|212217|的特定步骤|212218|这是同时具有因式分解的代码分组，这是很容易识别的，它的任何位置，去向和诸如此类的东西。然而，它允许不用过于具体的代码来扰乱这些公共类。|212219|所有这些类之间的连接都是由spring处理的(使用cucumber+spring，一旦您掌握了它的诀窍，它就会做得很好)。|212220|entityMap^0|0|0|0|1|1|1|1|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|15|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|16|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|17|8|@]|9|@]|A|$]]|$1|L|3|M|5|G|7|18|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1B|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|S|3|T|5|G|7|1D|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1E|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1F|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1G|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|11|$]]

On the current project I am taking part in, we asked ourselves the very same question.

After fiddling a bit with the possibilities, what we opted for was a mix of both the solutions you exposed.

<ul>
<li>Have steps regrouped in theme-centric common steps classes

<ul>
<li>app-start steps</li>
<li>security check steps</li>
<li>[place random feature concern here] steps</li>
</ul></li>
<li>And classes of scenario (and in some case even feature) specific steps</li>
</ul>

This was to have at the same time the grouping of factorized code which is pretty easily identifiable on it's whatabouts, whereabouts and whatnot.
Yet it allows not to clutter those common classes with overly specific code.

The wiring between all these classes is handled by spring (with cucumber spring which does a great job once you get the hang of it).

We are considering to use Cucumber on our project for acceptance testing.

When we write a <code>scenario</code> in a Cucumber <code>feature</code>, we write a list of <code>Given</code>, <code>When</code> and <code>Then</code> statements.

As we use <a href="https://github.com/cucumber/cucumber-jvm" rel="noreferrer">cucumber-jvm</a> project, the <code>Given</code>, <code>When</code> and <code>Then</code> statement are related to Java methods in (JUnit) classes.

I want to know what is the best organization for the code related to <code>Given</code> / <code>When</code> / <code>Then</code> in the project structure. My main concern is the maintenance of the cucumber tests on a big project, where the number of scenario is quite important, and especially regarding the items that are shared between features.

I can see at least 2 main approaches:

<ol>
<li>Each feature is related to it's own JUnit class. So if I have a <code>foo/bar/baz.feature</code> cucumber file, I will find the releated <code>foo.bar.Baz</code> JUnit class with the adequate <code>@Given</code>, <code>@When</code> and <code>@Then</code> annotated methods.</li>
<li>Separate <code>@Given</code>, <code>@When</code> and <code>@Then</code> methods into "thematic" classes and packages. For example, if in my cucumber scenario I have a statement <code>Given user "foo" is logged</code>, then the <code>@Given("^user \"([^\"]*)\" is logged$")</code> annotated method will be located in the <code>foo.user.User</code> class method, but potentially, the <code>@When</code> method used later in the same cucumber scenario will be in a different Java class and package (let say <code>foo.car.RentCar</code>).</li>
</ol>

For me, the first approach seems good in the way that I can easily do the relation between my cucumber features and my Java code. But the drawback is that I can have a lot of redundancies or code duplication. Also, it may be hard to find a possible existing <code>@Given</code> method, to avoid to recreate it (the IDE can help, but here we are using Eclipse, and it does not seem to give a list of existing <code>Given</code> statement?).

The other approach seems better essentially when you have <code>Given</code> conditions shared among several cucumber feature, and thus I want to avoid code duplication. The drawback here is that it can be hard to make the link between the <code>@Given</code> Java method and the <code>Given</code> cucumber statement (maybe, again, the IDE can help?).

I'm quite new to cucumber, so maybe that my question is not a good question, and with time and experience, the structure will be self-evident, but I want to get good feedbacks on its usage...

Thanks.

How to organize the specs definition in Cucumber?

集成开发环境

验收测试

Eclipse

Java

我们正在考虑在我们的项目中使用Cucumber进行验收测试。当我们在Cucumber feature中编写scenario时，我们会编写一系列Given、When和Then语句。当我们使用项目时，Given、When和Then语句与(JUnit)类中的Java方法相关。我想知道在项目结构中，与Given / When ...

问如何组织Cucumber中的规格定义？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何组织Cucumber中的规格定义？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何组织Cucumber中的规格定义？
EN