3 ms·

What are the advantages of a solution like this, over: [1] Selenium (http://www.seleniumhq.org http://www.seleniumhq.org), [2] scriptable testing, like Groovy

What are the advantages of a solution like this, over: [1] Selenium (http://www.seleniumhq.org http://www.seleniumhq.org), [2] scriptable testing, like Groovy's Geb (http://www.gebish.org http://www.gebish.org), which uses Selinium's core WebDriver component under the covers, or [3] scriptable headless browsing without using a real browser engine, such as with Python's Mechanize (http://wwwsearch.sourceforge.net/mechanize http://wwwsearch.sourceforge.net/mechanize)? Is this pretty much bullet #3, just for people who want to use "full-stack JavaScript" everywhere?

methyl 12y ago
This type of solution is faster than Selenium, at least when talking about PhantomJS, as well as it's headless so it does not require running graphical environment. Bullet #2 is basically the same as #1, and advantage over #3 is that Mechanize won't run Javascript, so it's useless eg. for testing Single Page Applications.
- StevePerkins 12y ago
  Hmm... can you elaborate further on that last point? I totally understand the value of headless browser testing, when you're not checking for browser-specific issues. However, I'm less clear on how a headless test runner's implementation language should ever matter one way or the other. If you're testing the behavior of a web application as it receives HTTP requests, then shouldn't the application be agnostic about which clients are sending those requests? If your test runner is reaching around the HTTP protocol and directly manipulating JavaScript on the rendered page, then doesn't that affect the reliability of the test suite... since it no longer represents true HTTP client interaction?
  - orkj 12y ago
    I think what he was saying was: If I have a webpage that only does one thing, it executes alert('Hello world'); Then the headless solution would have to be able to check that the alert fired. If your testing framework does not execute the JavaScript on the page (i.e just fetching the resources) then you are back to square one. I have no idea if Mechanize executes page JavaScript, but SlimerJS (and PhantomJS) does. Which is the difference here. * execute alert will probably for most use cases be bootstrapping some MVC and setting properties, doing navigation and so on.
    - StevePerkins 12y ago
      Whatever JavaScript a web page runs, shouldn't it be driven by some kind of event though? Rather it be the "onLoad" event itself, or the user clicking/hovering/changing something, etc. In a real use case setting, you wouldn't have users load a web page and then somehow arbitrarily execute JavaScript code directly, without any particular event firing. So why wouldn't you test through the relevant events?
  - delluminatus 12y ago
    I don't know what your question means, especially the "reaching around the HTTP protocol" part, but I'm going to try to answer it anyway. Mechanize doesn't contain a JS engine, so it can't scrape sites that rely on JS execution. You can't use it, for example, to scrape (or run tests on) content that was loaded via AJAX. The other scrapers in question do include a JS engine, so you can use them to scrape or test pages that load content dynamically. Because more and more Web sites are implemented as client-side single-page applications (SPAs), the ability to scrape dynamic content is becoming more important.
mootothemax 12y ago
Selemium is noticeably slow, and "Full-stack JavaScript" is vital for our primary SlimerJS use case: taking screenshots of webpages. As a sidenote, there's a very interesting docker container that gets Selenium up and running heedlessly with Chrome and Firefox: https://registry.hub.docker.com/u/vvoyer/docker-selenium-firefox-chrome/ https://registry.hub.docker.com/u/vvoyer/docker-selenium-fir... Whilst it's still slow, to suddenly have headless automated acceptance tests on real browsers is incredibly cool!
- tempVariable 12y ago
  >https://registry.hub.docker.com/u/vvoyer/docker-selenium-firefox-chrome/* https://registry.hub.docker.com/u/vvoyer/docker-selenium-fir... Awesome. I've been running headless selenium firefox with virtual frame buffer.
vorg 12y ago
There's some of us out there who don't like Groovy's ecosystem or Python's syntax. Groovy changes its direction every few years -- first it was a scripting language, then a MOP for Grails, then a DSL for Gradle et al, then statically-compiled to compete with Java, and soon a toy language for Android. Python's indent-based syntax puts a lot of people off. Javascript, while not great, doesn't have the killers that other languages and echosystems have.

methyl 12y ago

This type of solution is faster than Selenium, at least when talking about PhantomJS, as well as it's headless so it does not require running graphical environment. Bullet #2 is basically the same as #1, and advantage over #3 is that Mechanize won't run Javascript, so it's useless eg. for testing Single Page Applications.

StevePerkins 12y ago
Hmm... can you elaborate further on that last point? I totally understand the value of headless browser testing, when you're not checking for browser-specific issues. However, I'm less clear on how a headless test runner's implementation language should ever matter one way or the other. If you're testing the behavior of a web application as it receives HTTP requests, then shouldn't the application be agnostic about which clients are sending those requests? If your test runner is reaching around the HTTP protocol and directly manipulating JavaScript on the rendered page, then doesn't that affect the reliability of the test suite... since it no longer represents true HTTP client interaction?
- orkj 12y ago
  I think what he was saying was: If I have a webpage that only does one thing, it executes alert('Hello world'); Then the headless solution would have to be able to check that the alert fired. If your testing framework does not execute the JavaScript on the page (i.e just fetching the resources) then you are back to square one. I have no idea if Mechanize executes page JavaScript, but SlimerJS (and PhantomJS) does. Which is the difference here. * execute alert will probably for most use cases be bootstrapping some MVC and setting properties, doing navigation and so on.
  - StevePerkins 12y ago
    Whatever JavaScript a web page runs, shouldn't it be driven by some kind of event though? Rather it be the "onLoad" event itself, or the user clicking/hovering/changing something, etc. In a real use case setting, you wouldn't have users load a web page and then somehow arbitrarily execute JavaScript code directly, without any particular event firing. So why wouldn't you test through the relevant events?
- delluminatus 12y ago
  I don't know what your question means, especially the "reaching around the HTTP protocol" part, but I'm going to try to answer it anyway. Mechanize doesn't contain a JS engine, so it can't scrape sites that rely on JS execution. You can't use it, for example, to scrape (or run tests on) content that was loaded via AJAX. The other scrapers in question do include a JS engine, so you can use them to scrape or test pages that load content dynamically. Because more and more Web sites are implemented as client-side single-page applications (SPAs), the ability to scrape dynamic content is becoming more important.

mootothemax 12y ago

Selemium is noticeably slow, and "Full-stack JavaScript" is vital for our primary SlimerJS use case: taking screenshots of webpages. As a sidenote, there's a very interesting docker container that gets Selenium up and running heedlessly with Chrome and Firefox: https://registry.hub.docker.com/u/vvoyer/docker-selenium-firefox-chrome/ https://registry.hub.docker.com/u/vvoyer/docker-selenium-fir... Whilst it's still slow, to suddenly have headless automated acceptance tests on real browsers is incredibly cool!

tempVariable 12y ago
>https://registry.hub.docker.com/u/vvoyer/docker-selenium-firefox-chrome/* https://registry.hub.docker.com/u/vvoyer/docker-selenium-fir... Awesome. I've been running headless selenium firefox with virtual frame buffer.

vorg 12y ago

There's some of us out there who don't like Groovy's ecosystem or Python's syntax. Groovy changes its direction every few years -- first it was a scripting language, then a MOP for Grails, then a DSL for Gradle et al, then statically-compiled to compete with Java, and soon a toy language for Android. Python's indent-based syntax puts a lot of people off. Javascript, while not great, doesn't have the killers that other languages and echosystems have.