2

One of my clients is interested in using Cucumber. But I still have few questions about that:

  1. Should the dev team adapt their code to the Gherkin file?
  2. Should we start a project from scratch to follow Cucumber pattern?
  3. where should we store our spec files (.feature files)? Should we just leave them in a eclipse's folder? Should we upload them on a test management tool such as Testing? What are the best practices to manage them?
  4. I used to work with Selenium Page Object Model and store my test cases in Testink. Am I supposed to replace that by a full Cucumber solution? It looks like Cucumber's best practices are not compatible with Page Object Model. Am I wrong?

Any helps would be appreciated. Thank you guys.

Antoine Tran
  • 31
  • 2

1 Answers1

2

This is partly a matter of opinion. I will offer my view. Other may have different views.

  1. The code should not be adopted to Cucumber. The code should be testable. This happens to be in line with what you need to be able to connect to the code from a test, or a step in Cucumber.

  2. There is no need to start from scratch. If the code is testable, it will be possible to drive the development using Behaviour-Driven Development (i.e. Conversations, Concrete examples, Automated acceptance tests, Code, in that order). Starting to use BDD on an existing project/product is possible and in most cases necessary as you already have a goal with your work. BDD is just a mean, not a goal.

  3. The feature files should be stored with the source code. That is, it should be version controlled the same way as the rest of your code. It has to be available when your continuous integration server, Jenkins or similar, builds the system after each commit. If you store them somewhere else, you will end up with problems building and verifying the system.

  4. There is no conflict between Cucumber and the Page Object Pattern. The scenarios you create, i.e. the concrete examples of how the system should work, are converted to steps that actually perform something. A good habit is to delegate from the steps to helper objects. An example of these helpers are Page Objects.

It sounds to me that you need to learn more about Behaviour-Driven Development and Cucumber.

I have some resources that might help you.

Thomas Sundberg
  • 4,098
  • 3
  • 18
  • 25
  • Thank you Thomas. I really appreciate your input. And yes, you're right, I'm totally new with Cucumber. I need to dig down again but you helped me a lot so far. I'll have a deep look at your link too. – Antoine Tran Oct 17 '17 at 13:59
  • I am glad that I was able to help you. – Thomas Sundberg Oct 18 '17 at 06:19
  • The conflict with PageObject and Cucumber starts to show when pages have shared functionalities. PageObject with Cucumber becomes additional abstraction and maintenance overhead because in Cucumber, the step definitions/methods themselves are already independent units. The design pattern is pervasive in the test automation community but using it with Cucumber is actually anti-pattern. You don't have to use it in _every_ framework. – k_rollo Jul 15 '18 at 13:11
  • In our case, we move from "PageObject" model to a "Components" model, covering functionalities such as "authentication", "navigation", "purchase", etc. This fits better with Cucumber. Also, here you can find a interesting post about [Cucumber best practices](https://blog.redsauce.net/tag/Gherkin). – Pablo Gómez Jul 08 '21 at 10:20