SlimerJS – A scriptable browser for Web developers
slimerjs.org
slimerjs.org
Use http://casperjs.org scripts, and then choose the best engine at runtime.
For example, need screenshots? Tell CasperJS to use SlimerJS.
Looking for faster rendering to HTML? Tell CasperJS to use PhantomJS.
[0] http://phantomjs.org/screen-capture.html
[1] http://docs.casperjs.org/en/latest/modules/casper.html#captu...
Sorry, that's my fault for not going into more detail :)
The big issue I have with PhantomJ's screenshots is that it doesn't support web fonts, and so pages don't render correctly.
* with minor changes, as documented with SlimerJS
[1] Selenium (http://www.seleniumhq.org),
[2] scriptable testing, like Groovy's Geb (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)?
Is this pretty much bullet #3, just for people who want to use "full-stack JavaScript" everywhere?
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.
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?
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.
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?
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.
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-fir...
Whilst it's still slow, to suddenly have headless automated acceptance tests on real browsers is incredibly cool!
Awesome. I've been running headless selenium firefox with virtual frame buffer.
Hah, funnily enough, that's the exact same reason we're using it as well!
PhantomJS's "it'll be ready when it's ready" release cycle has been a bit frustrating, especially with version 2 and its support for custom fonts.
It's a shame there's no one perfect solution: PhantomJS is great, shortcomings aside; and SlimerJS is near perfect but slow, slow, slow.
Selenium if you want to support all browsers, including mobile.
PhantomJS if you want a performant and easy solution.
SlimerJS if you want PhantomJS but want HTML5/CSS3, too (or just need Firefox).
My 2 cents
Browser testing is becoming a case for the Ghostbusters!