Example showing how to test a web application

[mikeymckay]

I would like to be able to do something like this:

node cucumber.js features

This will load a web page and all the javascript that it depends on (defined in support/env.js?).

It will then execute all of the features against that loaded web page.

This is the sort of workflow I expected to be able to accomplish with node, but I can't see how to do it.

Any help?

Mike

[jbpros]

Hey Mike,

Thank you for the suggestion.

Cucumber.js is - as you probably know - running within both Node.js and web browsers. A little example exists already (run node example/server.js and go to http://localhost:9797); it demonstrates how to run Cucumber.js right from within a browser.

There are two ways (probably others?) of using cucumber.js to run against a web app:

Inside browsers

This is one way to test web applications: run cucumber on top of your application, inside the browser.

Pros

• Testing against real browsers
• Run the features on different platforms
• "Beta" testers could run your features without hassle
• ?

Cons

• Might be a bit slower due to the actual rendering of pages (but this has been tested yet)
• ?

Inside Node.js

Another way to run features against a web app - as you are suggesting - is to run the features from within Node.js (i.e. this is the headless approach). You might use a lib like the awesome zombie.js to browse the app and interact with it from the step definitions.

Pros

• Headless & self-contained (probably better for Continuous Integration servers and developers)
• Probably a bit faster (to be tested)
• ?

Cons

• Not real browsers, there might be slight differences
• ?

I like the idea of having demos for both approaches, it would definitely help people understand how this is all working.

It would be great if someone could send a pull request for this. I am currently polishing the cucumber.js' own test suit. Following that, I plan on adding important missing features listed in the 0.2 release issue list (tables, background, etc.).

Don't hesitate to ping me on #cucumber if you need more specific help to test your app!

Cheers.

[mikeymckay]

This is extremely helpful. Ideally we would have something like capybara,
where we have a universal set of web application related actions (follow
link, click button, fill in text) sitting on top of drivers that plug into a
specific browser (zombie, firefox, chrome). Then you can write your actions
once and test across all sorts of browsers. If it was capybara compatible,
then people with capybara cucumber features could seamlessly switch to using
cucumber.js which would be super cool (especially since javascript support
is less than ideal under regular cucumber). I'll look for you on #cucumber
when I get cuking on this.

On Thu, Jul 28, 2011 at 5:39 AM, jbpros <
reply@reply.github.com>wrote:

Hey Mike,

Thank you for the suggestion.

Cucumber.js is - as you probably know - running within both Node.js and web
browsers. A little example exists already (run node example/server.js and
go to http://localhost:9797); it demonstrates how to run Cucumber.js right
from within a browser.

There are two ways (probably others?) of using cucumber.js to run against a
web app:

Inside browsers

This is one way to test web applications: run cucumber on top of your
application, inside the browser.

Pros

• Testing against real browsers
• Run the features on different platforms
• "Beta" testers could run your features without hassle
• ?

Cons

• Might be a bit slower due to the actual rendering of pages (but this has
  been tested yet)
• ?

Inside Node.js

Another way to run features against a web app - as you are suggesting - is
to run the features from within Node.js (i.e. this is the headless
approach). You might use a lib like the awesome zombie.js to browse the app and interact with it from
the step definitions.

Pros

• Headless & self-contained (probably better for Continuous Integration
  servers and developers)
• Probably a bit faster (to be tested)
• ?

Cons

• Not real browsers, there might be slight differences
• ?

I like the idea of having demos for both approaches, it would definitely
help people understand how this is all working.

It would be great if someone could send a pull request for this. I am
currently polishing the cucumber.js' own test suit. Following that, I plan
on adding important missing features listed in the 0.2 release issue list
(tables, background, etc.).

Don't hesitate to ping me on #cucumber if you need more specific help to
test your app!

Cheers.

Reply to this email directly or view it on GitHub:
#23 (comment)

[jbpros]

I've put together a small demo. It's just a start. Next thing: add a complete README documenting it all.

[olivoil]

Hi, I setup an example app here. It's just a start as well. Running the features is explained in the README, you can browse the setup for cucumber in test/features and see the command used to run them in the Makefile. Let me know if you have any feedback!

[jbpros]

@olivoil Nice work! Thank you for sharing this.

You could improve the way World is handled. this in the sharedSteps closure has a World property that is expected to be a constructor to your World object. Tell Cucumber what World constructor should be used, by setting the aforementioned property to your constructor. See this example.

Instead of returning an instance of your World when exporting the module, you would export the constructor and let Cucumber instantiate it.

The benefit of it is that Cucumber will instantiate a new object for each scenario. This will guarantee a clean state between scenarios.

[olivoil]

@jbpros Thanks for the tip! I'll push the changes tonight :) I included a pull-request to update the readme with more usage information. Hope this helps!

[Vaishnavi-R]

@jbpros
Hello! I am doing an End-to-End API testing for my application with Electron.
In one of the scenarios, I need to check the API which is called by front-end react button. Is there any way to check the click event in Cucumber? Appreciate any help. Thanks!

[charlierudolph]

There is nothing built into cucumber specifically to do that. Cucumber connects the gherkin in the feature files to JavaScript functions and outputs the results. Writing the functions that clicks and the function that verifies the API was called is up to you. There are plenty of other libraries out there that should be able to help.

From a testing standpoint, it might make sense to have your tests hit a local deployment or a mock version of your API. After you click the proper button, you can check that the API method was called (if using a mock) or the effect of calling the API method (if using a local deployment)

[Vaishnavi-R]

Thanks much @charlierudolph !

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.