How to make PhantomJS default
0o-de-lally opened this issue · 8 comments
@awatson1978
My preference is Casperjs, but I see that the project is inactive. So I'm trying this, but there's more config and learning curve than I expected.
Is there a reason Phantomjs is not the default here (and bundled with)? Also, wish there was some documentation on changing to Phantom if that is possible.
FYI, my main use is for CI, so I wish we didn't have to manage the dependencies here.
Hi keyscores,
The reason that Firefox is the default is for a couple of reasons: first, it's what's shipped as the default of Nightwatch, which is a library I'm not in control of; so we're using what they have as a default. Second, it helps with the learning and implementation curve... having a full browser allows people to see how the framework is walking through the app, helps them debug and write tests, and generally. The idea is that most people are going to write tests on their local workstations before they load them up to a CI server.
That being said, we're running the current Nightwatch setup with Firefox on Travis CI without any problems. Here's an example repo, with associated reports, build history, and status badges:
https://github.com/awatson1978/minimongo-table
https://travis-ci.org/awatson1978/minimongo-table
https://travis-ci.org/awatson1978/minimongo-table/builds
However, if that doesn't work for you, feel free to dive into the Nightwatch Developer docs...
http://nightwatchjs.org/guide#settings-file
Post questions on the Nightwatch google group...
https://groups.google.com/forum/#!forum/nightwatchjs
And research using PhantomJS with Selenium (which Nightwatch is based on). You're not the only person asking about it, and there's been a bit of work done on it.
http://code.tutsplus.com/tutorials/headless-functional-testing-with-selenium-and-phantomjs--net-30545
https://github.com/beatfactor/nightwatch/wiki/Running-tests-in-PhantomJS
Keep us posted of any progress you make, and good luck!
Thanks Abigail for a very thoughtful message. Maybe consider exposing this
specific config. Perhaps an object which sets the webdriver. It would be
more practical than creating our own package with the nightwatch configs.
Thanks again
Lucas Geiger
On Mon, Feb 2, 2015 at 8:13 PM, Abigail Watson notifications@github.com
wrote:
—
Reply to this email directly or view it on GitHub
#5 (comment)
.
Hi @keyscores,
without wanting to steal @awatson1978's thunder for her work here, I would recommend using gulp-nightwatch-headless, which comes with the Nightwatch-PhantomJS integration out-of-the-box. You can see an example Nightwatch configuration that worked for me here. In the end, I chose to still use Firefox, as some of my tests would fail under PhantomJS, but it's a simple configuration change either way.
Hope this helps,
Ivan
Oh, it's no problem. I'm getting ready to deprecate clinical:nightwatch for a new cli utility I've been working on anyway. The new utility is going to be able to launch any number of test runners, and it would be great to include gulp-nightwatch-headless as a run option. Do you have an example of the command that you're run on the command line using gulp-nightwatch-headless? How does it get launched? Or is it just included in another npm app? (Which is totally fine.)
FYI, the new utility isn't published to NPM quite yet, so it needs a 'npm install -g' after cloning locally. But it's only a day or two away. Almost there!
Ooh, StarryNight looks interesting! We certainly need a better Nightwatch-Meteor integration, which is what you appear to have started. Cool stuff.
Right now, I'm just running running gulp-nightwatch-headless via Gulp. You can see the instructions here.
I really think we should avoid reinventing existing tools, which is why I avoided using your run_nightwatch.sh script (sorry!). Gulp works great as a task runner, and we should leverage existing npm packages as much as possible. But I agree that better Meteor integration is needed. For example, it would be great if I could use Meteor and my collections from within Nightwatch tests. A possible use case that I needed recently is clearing out the test database before each test run. As it is, I'll have to work that into a Gulp task, which is not ideal.
Anyway, I've steered off the discussion in this issue, but perhaps we can continue this elsewhere(?). In the meantime, I'll be looking forward to StarryNight, and perhaps even help out, if I'm able to.
Cheers,
Ivan
No worries about avoiding the run_nightwatch.sh script. I've been trying to get rid of it ever since I wrote it! Just didn't know how to replace. I asked everybody for help.... MDG, Velocity, meetups... but eventually it just took a ton of research to slowly refactor each piece of the run_nightwatch.sh script into native node. And in the process, figuring out how to write a cli tool.
Looking at the instructions, I think it's going to be pretty straightforward to integrate. What would a good API syntax be? Maybe something like the following?
starrynight -run-tests acceptance phantom
starrynight -run-tests phantom-acceptance
I think the big win with using gulp to launch nightwatch is that we can get the phantom integration. Firefox integration can be done with the existing integration; so I'm not too worried about exposing the different browsers via gulp. Which might make the second version a bit more simple to do.
Oh, by the way, take a look at issue #8 for a way to access Meteor calls. At the very least, you could set up some Meteor.methods to clear the database for you. I've been thinking a helper package with debugOnly that provides a few such meteor methods might be very hand. Very excited to finally have this run_nightwatch.sh script out of the way, so I can focus on these other items.
Hi Abigail,
I'm a big fan of reusing existing tools, and making another CLI tool for developers to manage/adapt into their workflow would be at the bottom of my list. That said, if what you're trying to achieve can't be done by Gulp tasks alone, you don't even need to use Gulp to use gulp-nightwatch-headless. Other than gulp-util, the script doesn't have any hard Gulp dependencies, and could probably be used by simply requiring the exported function. If that's not an option, what it does is fairly simple and could possibly be forked and adapted to what your tool needs.
As for the CLI, I'm not a fan of the hyphen prefix for what are essentially commands, right? In traditional POSIX tools, hyphens are reserved for options. So you could have something like:
starrynight run-tests --type acceptance --browser phantomjs
With support for short options, unique prefixes (e.g. sn r -t a -b p could accomplish the same as the above), and sane defaults (so sn run would run all available tests on PhantomJS). Ideally, this should already be handled by a library. I see you're using minimist, so not sure if it supports that. Add configuration support to that, and writing a good CLI tool is not that straightforward. :)
Anyway, just a thought. If you want, I'd be happy to discuss further issues, just ping me on a new issue on the starrynight project, to give keyscores' inbox a rest. :)
And thanks about the Meteor.methods suggestion. I'll look into it.