问题描述:

I'd like to ask what's the practical difference between Cucumber and JUnit. I haven't worked with Cucumber at all; found some documentation but I'd greatly appreciate some feedback from someone who has worked with both (interested in a high lvl overview).

To break it down - what i'm interested in (I'll be using Selenium and not Protractor) :

  1. Are there any things that Cucumber can't do vs Junit.
  2. What's easier to use (coding, how fast you can write the tests) ?
  3. Both work with Page Objects?

Some things that i need to get done

  1. Test css styling
  2. Test page responsiveness
  3. Standard operation on WebElements (clicking, getting data etc)
  4. Asserts.

Anything in addition to this is more than welcomed. Greatly appreciate your answer on this, thank you!

网友答案:

JUnit and Cucumber are aiming at different goals. They are rather complement to each other than replace each other.

Are there any things that Cucumber can't do vs Junit.

There isn't anything you can do with JUnit that you can't do with Cucumber. And the other way around.

The difference is that while JUnit aims at tests, Cucumber aims at collaboration with non technical people. Non technical people will not understand what a unit test does. They will, however, be able to understand and validate an example written in Gherkin.

What's easier to use (coding, how fast you can write the tests) ?

There is more overhead when you use Cucumber. You will have to implement each step as a method and not just one test method as you would do if you used JUnit. The readability you gain from expressing examples using plain text is sometimes worth the extra.

Both work with Page Objects?

Page Objects are an abstraction for the web page you are verifying. It is a class you write as developer/tester. The Page Objects can be used by both JUnit and Cucumber. In fact, there is no difference between the tools from that perspective.

The choice to use JUnit or Cucumber is a matter of granularity and audience.

A work flow that works well is to mix the tools. Define examples of how the application should work using BDD, (Cucumber, Gherkin). Implement these scenarios using Cucumber. Then, use JUnit to work out details that may be important but not necessary important for the business stakeholders at a high level. Think of corner cases that are important but are too much details for your stakeholders.

An image that describes this mix is available here: https://cucumber.io/images/home/bdd-cycle.png

I wrote blog post a while back where I talk about the right tool for the job: http://www.thinkcode.se/blog/2016/07/25/the-right-tool-for-the-job

The right tool may be Cucumber. It can also be JUnit. It all depends on your audience.

网友答案:

Simply spoken, those two work on completely different levels of abstraction.

JUnit is mainly an automation framework; giving you the ability to rapidly write down test cases using the Java programming language. It provides annotations that make to easily declare: "this method over here is a JUnit test". It was intended as framework for unit tests; but many people also use it to drive full scale "integration" or "function" tests.

Cucumber on the other hand works on a much higher level of abstraction. You start by writing "test descriptions" in pure text. Leading to probably the key difference: you don't need a to know Java to write a cucumber test (you just need a java programmer to provide the "glue code" that allows Cucumber to turn your text input into some executable piece of code).

In that sense, you are somehow asking us to compare apples and turnips here; as one would be using these two toolsets for a different set of "problem solution". But as lined out; you can also use JUnit to drive "bigger" tests; so the main differentiation between these two tools is the level of abstraction that you are dealing with.

EDIT: your comment is correct; as those tools are for different "settings", you shouldn't expect that a non-technical person alone will be able to use cucumber to write good tests covering everything. Cucumber is a nice way to enable non-technical participation for creating tests; but in the end, you are solving technical (java related) problems; thus you need Java programming expertise at some point. Either "within the same person"; or at least within different people in your team.

相关阅读:
Top