Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing cucumber-electron

cucumber.io

Post reply on HN
Print view View original

21–30 of 31 posts

Re: Announcing cucumber-electron

#21

Post by joshski »

yebyen wrote: post #2

This sounds very interesting. I have been using cucumber in my development with Selenium WebDriver (cucumber-rails) and the author here has promised things that were missing in PhantomJS and Capybara-WebKit that drove me toward using Selenium and Chrome instead. Namely the option of running in either Headed mode with the inspector available, or Headless. Does this project require your system-under-test to be a pure N…

Yes you can use it to describe and automate systems built in other technologies and I've done that on a couple of projects. It's a good fit for any web app with a lot of client-side code. But its sweet spot is definitely node.js apps.

You could certainly use electron as a driver for tests written in other tech, but there is no capybara electron driver that I'm aware of. Using cucumber-electron means you write your step definitions (automation code) in JavaScript.

(I'm the author of cucumber-electron)

Re: Announcing cucumber-electron

#22

Post by [deleted] »

yebyen wrote: post #2

This sounds very interesting. I have been using cucumber in my development with Selenium WebDriver (cucumber-rails) and the author here has promised things that were missing in PhantomJS and Capybara-WebKit that drove me toward using Selenium and Chrome instead. Namely the option of running in either Headed mode with the inspector available, or Headless. Does this project require your system-under-test to be a pure N…

[deleted]

Re: Announcing cucumber-electron

#24

Post by fake-name »

SigmundA wrote: post #8
cyrusroshan wrote: post #7

Earlier quoted context omitted.

I write tests using chromedriver. Ends up being really simple to write, and if I want to debug something, it's just a chrome instance that I can use normally if I make the tests wait. Only downside is you have to make it run with xvfb on the CI server, but that's pretty easy to set up in your config file usually.

Is headless Chrome working yet? https://chromium.googlesource.com/chromium/src/+/lkgr/headle...

It works, but there are a number of issues in the remote control protocol.

(note: I am developing a python wrapper for controlling it: https://github.com/fake-name/ChromeController )

I've been meaning to see about wrapping the C++ api as a python module, but not had time.

Re: Announcing cucumber-electron

#25

Post by joshski »

yebyen wrote: post #5
stu_k wrote: post #3

The title is slightly misleading. This just looks like an alternative way to run Cucumber, not a complete alternative to Selenium.

It didn't even occur to me that there were other ways of using Selenium than Selenium-WebDriver!

This is not an alternative way of using selenium. It's a way to avoid using selenium. The advantage over selenium is that tests and application code are run in the same process, so they tend to be faster, less brittle and easier to debug. The downside is that they are not cross-browser.

Re: Announcing cucumber-electron

#26

Post by yebyen »

joshski wrote: post #21
yebyen wrote: post #2

This sounds very interesting. I have been using cucumber in my development with Selenium WebDriver (cucumber-rails) and the author here has promised things that were missing in PhantomJS and Capybara-WebKit that drove me toward using Selenium and Chrome instead. Namely the option of running in either Headed mode with the inspector available, or Headless. Does this project require your system-under-test to be a pure N…

Yes you can use it to describe and automate systems built in other technologies and I've done that on a couple of projects. It's a good fit for any web app with a lot of client-side code. But its sweet spot is definitely node.js apps. You could certainly use electron as a driver for tests written in other tech, but there is no capybara electron driver that I'm aware of. Using cucumber-electron means you write your st…

Thanks for showing up and answering questions!

I've gotten used to having my rails application (server) running in the same thread as my cucumber (client-side) steps, thanks to cucumber-rails. So I could see why this would be especially useful for testing node.js applications, with the same advantages. (A fault detected anywhere on either side of the test execution, client or server, can be escalated and reported to stop the entire test, delivering a really good, clear idea of where to look in the code for the violator!)

This looks like a really neat project.

Re: Announcing cucumber-electron

#27

Post by yebyen »

joshski wrote: post #25
yebyen wrote: post #5

Earlier quoted context omitted.

It didn't even occur to me that there were other ways of using Selenium than Selenium-WebDriver!

This is not an alternative way of using selenium. It's a way to avoid using selenium. The advantage over selenium is that tests and application code are run in the same process, so they tend to be faster, less brittle and easier to debug. The downside is that they are not cross-browser.

There are also other ways of using Selenium, though, that I had mentally disregarded and ignored as probably not useful.

You can also get this behavior (basically single thread of execution) with cucumber-rails and Selenium (or probably any driver other than Selenium, for that matter). I'm not saying the application code is literally run in the same thread or process as the test executor, but in effect they do. Your Ruby process is in charge of setting up the HTTP server, as well as driving whatever driver (Selenium, Phantom, ...) you're using for Cucumber.

So serendipitously, with (MRI) Ruby being a single-threaded beast, you do still get that behavior and quality of being able to catch errors that pop up on either side, making it much easier to debug misbehaving server or tests.

Re: Announcing cucumber-electron

#28

Post by jedifans »

seanwilson wrote: post #13

Can anyone explain why you would want to use Cucumber? I heard it enables non-programmers to write the tests themselves but I don't see that as realistic as non-programmers don't have the training to specify requirements rigourously. At least with coded tests you can use IDEs to validate and refactor your tests.

Cucumber and other tools such as Behat allow you to capture conversations you have with your client, product owner and stakeholders.

They enable you to build the right thing - the thing that helps the users or meets the business goals.

Have a look for BDD, Behaviour Driven Development.

The main thing is to have the conversations. The automated tests are a lovely side effect!

Re: Announcing cucumber-electron

#29

Post by jedifans »

rukenshia wrote: post #17
seanwilson wrote: post #13

Can anyone explain why you would want to use Cucumber? I heard it enables non-programmers to write the tests themselves but I don't see that as realistic as non-programmers don't have the training to specify requirements rigourously. At least with coded tests you can use IDEs to validate and refactor your tests.

We use cucumber at work for a few weeks now. Our product owner actually writes the initial feature files for our end-to-end tests and we refine them. We keep sending him back on what we changed and why, and the product owner learns from that and tries to do it the next time. We started doing this around 6 weeks ago and it is helping us developers a lot in my opinion, as well as getting some work off of us. Sure, we n…

Before the feature files get written, have a conversation with the PO and other stakeholders.

Involve a QA person and relevant developers.

Catch the changes early, ask for more examples of the feature or goal, "have you thought about ...", "What happens in this case...?".

You will get better quality features with less rework, because you are writing the thing the PO actually wants and cover off edge cases before they crop up in testing.

Re: Announcing cucumber-electron

#30

Post by jedifans »

yebyen wrote: post #19
seanwilson wrote: post #13

Can anyone explain why you would want to use Cucumber? I heard it enables non-programmers to write the tests themselves but I don't see that as realistic as non-programmers don't have the training to specify requirements rigourously. At least with coded tests you can use IDEs to validate and refactor your tests.

I can tell you why I'm using it, and it's not to enable non-programmers to write tests. (Not anymore, it was at first...) The number one advantage is that using Cucumber produces human-readable documentation that is also executable, and through the magic of CI is prevented from becoming stale. I use Cucumber with Rails, and I've actually heard a lot of really good arguments not to use Cucumber. The one thing these al…

Try not to see a feature file as a way to automate tests but to capture the requirements in a language that isn't technical.

Business rules change far less often than implementations, so the feature files shouldn't be tied to the implementation - that tying together can happen in the ruby code that implement the steps. You can refactor that code easily but the feature is denoting the business rule.

Post reply on HN