support and documentation for programmatic use as a Node.JS module

[jokeyrhyme]

My current project has a test suite Node.JS app that fires up a simple HTTP server and uses https://github.com/sgentle/phantomjs-node and bridge-code I wrote myself to programmatically start PhantomJS, point it at my browser test URLs, collect the results, and then include them in the results collected from the pure Node.JS tests.

Anyhow, I'm looking to replace phantomjs-node, as it looks like it is now unmaintained and is broken with PhantomJS 1.7.

I am not trying to pit your project against the other one, that would be silly. I would, however, prefer to be able to control the PhantomJS instance programmatically with your project in a similar fashion to the other project.

[jokeyrhyme]

I did find another Node.JS wrapper here: https://github.com/sheebz/phantom-proxy

[metaskills]

The one thing I like about my project is that it technically allows anyone with PhantomJS to use it. The long format of the command would look this this phantomjs lib/mocha-phantomjs.coffee test/mixed.html.

So all my logic is wrapped up in the mocha-phanomjs.coffee. Now most will use this with node and not have any issue installing it as an npm, but I do want to make this work for both equally. This decision kept me from doing a dependency on any node/phantom module and takes a simple high road and says, just install PhantomJS and have it in your path and this will work.

With all this said, I am open to suggestions, talking about it and the requesting good code in a pull request that is tested too. Thoughts?

[jokeyrhyme]

Having started using phantom-proxy, my immediate needs are addressed (although my tests now don't seem to be quite as deterministic as they used to be).

I think my main concern was that it seemed to me like there wasn't an actively-developed Node.JS bridge for PhantomJS. I'm glad to hear that you aren't against the idea, but your project does have a certain purity, and I certainly wouldn't want to divert your attention unnecessarily.

I have written code that uses PhantomJS to make browser-based Mocha tests look as though they were executed in Node.JS:

1. my Node.JS test runner finds all browser tests that need to run
2. for each one:
   • run a static web server for the browser test
   • run PhantomJS pointing at the browser test URL
   • after Mocha in PhantomJS finishes, pull the DOM out of PhantomJS and into Node.JS
   • for each test result, create an empty Node.JS test with a timer that matches the time taken in PhantomJS

[metaskills]

A few thoughts on that. It seems you are parsing the tests from the HTML served up by your server. If so, in this case this is something I never wanted to do. Other runners I saw in Jasmine and Mocha all parsed stuff out of the HTML reporter after the fact. I never liked that method which lost the flexibility to use all of Mocha's console friendly reporters.

A note on the other projects. I thought there were PhantomJS wrappers for node that kept parity with the name, like this one. It looks like it wraps phantomjs and allows a node user to treat it more natively. My hopes were given if this indeed did create a bin with the same name as the project it wraps, then users could opt to use that bin seamlessly. I would be open to any changes to make that happen, as long as it did not remove native PhantomJS binary compatibility.

[jokeyrhyme]

Regarding NPM phantomjs:
"This is an NPM wrapper and can be used to conveniently make Phantom available It is not a Node JS wrapper."

Regarding the HTML parsing, I would love to be able to avoid doing this. My approach is to basically fake the results in the outer Node.JS test so that they match the results in PhantomJS. I'm very open to a cleaner approach.

I am working with my company's existing code base, so some of the code isn't in a state where it would be easy to mock interfaces and unit test each module individually. I imagine most full-time developers are in this situation. So rather than refactor the code, I ended up running a special HTTP server with URL routes configured just well enough to fool the code into doing what was necessary to be tested. So this is why I need a bit more than just being able to run these tests individually from the command line.

[metaskills]

Closing this issue since #32 addresses it.