Casper.js (and Phantom, for that matter) has been pretty buggy and difficult to work with for me. Had better luck with Selenium, which makes me unhappy because I'd rather use something more code oriented.
(I've made this comment before on CasperJS/PhantomJS postings, but I've never gotten an answer.)
I love the idea, but I'm a bit worried that it's just webkit. Aren't all the other browsers important too? This is why I feel that Selenium still has a place, even though I agree that Casper is easier to use. Perhaps browserling is an appropriate answer?
I don't mean to disrespect CasperJS or PhantomJS, they're certainly wonderful tools, and any final automated functional test like this is infinitely better than none, but it's bad enough that people are developing for Webkit, do we really have to make it explicit by only testing on Webkit? ;)
Something else worth noting: the most recent release of PhantomJS actually has an implementation of the Selenium WebDriver protocol, so you can use that, if you wish:
I think the point of the person you're responding to, was that if you use the selenium interface with PhantomJS, you can change your testing browser to Firefox, Safari, etc with very little work on your part. i.e start with Phantom/Selenium, then test with the rest when you're ready.
Most likely your front-end/UI uses other libraries to handle cross-browser issues so your automation tests will focus on the functionality of the application as opposed to catching cross-browser bugs or performance issues.
The problem that PhantomJS solves is to run headless browser which is very useful for organization that runs their build/tests on their CI-server and would prefer minimal setups (as opposed to have "testing-labs" like the big guys [yahoo, ms, google]). That itself reduces the cost of development/testing cycle.
I prefer Testacular for exactly this reason. It allows you to capture any number of browsers. I've attached my physical iPad to it, and IE 8 out of a VM.
JsTestDriver and Test'em 'Scripts do too. (I haven't tried Test'em yet, but that's what I hear.)
Granted, these aren't tools for functional testing like Selenium and (apparently) CasperJS, but functional tests are something you want to minimize as much as possible. They're slow-running and brittle.
That's exactly what he was asking: Since @foo is shorthand for this.foo, why are the code snippets littered with this.method, this.prop, this.blah and the likes?
If you're looking to use Casper.js on a Django project, have a look at the small wrapper around LiveServerTestCase we wrote to make it easier to call Casper, pass params (like server url), and the like: https://github.com/dobarkod/django-casper
20 comments
[ 8.5 ms ] story [ 98.4 ms ] threadI love the idea, but I'm a bit worried that it's just webkit. Aren't all the other browsers important too? This is why I feel that Selenium still has a place, even though I agree that Casper is easier to use. Perhaps browserling is an appropriate answer?
I don't mean to disrespect CasperJS or PhantomJS, they're certainly wonderful tools, and any final automated functional test like this is infinitely better than none, but it's bad enough that people are developing for Webkit, do we really have to make it explicit by only testing on Webkit? ;)
http://phantomjs.org/release-1.8.html
The point of the parent is to test on multiple browsers.
Most likely your front-end/UI uses other libraries to handle cross-browser issues so your automation tests will focus on the functionality of the application as opposed to catching cross-browser bugs or performance issues.
The problem that PhantomJS solves is to run headless browser which is very useful for organization that runs their build/tests on their CI-server and would prefer minimal setups (as opposed to have "testing-labs" like the big guys [yahoo, ms, google]). That itself reduces the cost of development/testing cycle.
JsTestDriver and Test'em 'Scripts do too. (I haven't tried Test'em yet, but that's what I hear.)
Granted, these aren't tools for functional testing like Selenium and (apparently) CasperJS, but functional tests are something you want to minimize as much as possible. They're slow-running and brittle.