16

我们正在考虑在我们的项目中使用Cucumber进行验收测试。

当我们scenario在 Cucumber中编写 a 时feature，我们编写了Given,When和Then语句的列表。

当我们使用cucumber-jvm项目时Given，When和Then语句与（JUnit）类中的 Java 方法相关。

我想知道项目结构中与Given//相关的代码最好的组织是什么。我主要关心的是维护一个大项目的黄瓜测试，其中场景的数量非常重要，尤其是关于功能之间共享的项目。WhenThen

我可以看到至少两种主要方法：

  1. 每个特性都与它自己的 JUnit 类相关。所以如果我有一个foo/bar/baz.feature黄瓜文件，我会找到相关的foo.bar.BazJUnit 类，它有足够@Given的@When和@Then注释的方法。

  2. @Given将,@When和方法分离@Then到“主题”类和包中。例如，如果在我的黄瓜场景中我有一个语句Given user "foo" is logged，那么带@Given("^user \"([^\"]*)\" is logged$")注释的方法将位于foo.user.User类方法中，但可能@When稍后在同一黄瓜场景中使用的方法将位于不同的 Java 类和包中（比如说foo.car.RentCar） .

对我来说，第一种方法似乎很好，因为我可以轻松地处理我的黄瓜特性和我的 Java 代码之间的关系。但缺点是我可以有很多冗余或代码重复。此外，可能很难找到可能的现有@Given方法，以避免重新创建它（IDE​​ 可以提供帮助，但这里我们使用的是 Eclipse，它似乎没有给出现有Given语句的列表？）。

当您在多个黄瓜功能之间共享条件时，另一种方法似乎更好Given，因此我想避免代码重复。这里的缺点是很难在@GivenJava 方法和Givencucumber 语句之间建立联系（也许，IDE 可以提供帮助？）。

我对黄瓜很陌生，所以也许我的问题不是一个好问题，随着时间和经验，结构将是不言而喻的，但我想得到关于它的使用的良好反馈......

谢谢。

4

3 回答 3

2

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:

  • 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 SendEmail() function wouldn't be in a class called NewEmailScreenCommands, would it? It would be in EmailActions or some such.
    So the same applies here; structure your code according to what it does, and not who uses it.

  • 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.

  • Keeping code grouped by theme makes DRYing it much easier; you know exactly where all the code dealing with the user entity is, so it's easier for you to reuse it.

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

于 2014-03-06T13:42:18.507 回答
1

我们还开始使用 Cucumber-JVM 进行验收测试，并且在组织代码方面遇到了类似的问题。我们选择为每个功能设置 1 个步骤定义类。目前这很好，因为我们正在测试的功能不是很复杂，也不是很独立，我们的功能几乎没有重叠。

我认为您提到的第二种方法会更好，但是将几个不同的步骤定义类绑定到一个场景中通常具有挑战性。我认为一旦您开始添加更多功能并正常重构，最佳项目结构将变得更加清晰。

同时这里有一个黄瓜的 Eclipse 插件，

https://github.com/matthewpietal/Eclipse-Plugin-for-Cucumber

在编写功能时，它具有语法突出显示以及现有可用步骤的列表。

于 2012-10-18T10:09:36.933 回答
0

在我参与的当前项目中，我们问自己同样的问题。

在摆弄了一些可能性之后，我们选择的是您公开的两种解决方案的混合。

  • 在以主题为中心的通用步骤类中重新组合步骤
    • 应用程序启动步骤
    • 安全检查步骤
    • [在此处放置随机功能关注点] 步骤
  • 以及场景类别（在某些情况下甚至是功能）特定步骤

这是为了同时对分解代码进行分组，这些分解代码很容易识别它的行踪、行踪和诸如此类。然而，它允许不要用过于具体的代码混淆那些常见的类。

所有这些类之间的接线都由弹簧处理（一旦你掌握了黄瓜弹簧，它就会做得很好）。

于 2015-09-10T09:04:48.910 回答