-
Notifications
You must be signed in to change notification settings - Fork 25
Support PhantomJS #86
Comments
Looks like https://github.com/searls/jasmine-maven-plugin just released support for phantomjs so maybe you can leverage some of that work? |
@kc0dhb thanks for the update! I suppose I could, most likely 😸 |
Alright, after some looking into jasmine-maven-plugin and some thinking about how WebDriver works, the conclusion is the following: this is doable, however, not as simple as in the jasmine-maven-plugin case. The reason for this is that for pure testing instrumentation (meaning, changing the actual sources) is not required, thus the only thing that we would need is to run the tests and get the value of a certain JS variable (for example). However, instrumentation is currently done on the fly, by making use of HtmlUnit's script PreProcessor. To use the WebDriver implementation for PhantomJS, we need to:
As far as I can tell, this should do the trick and allow using any driver implementation there is. Thoughts? |
More thoughts: using WebDriver there's pretty much no way to know for sure that background JS has finished executing (unlike with pure HtmlUnit), not unless we want to deal with every testing library there is and support every single one in a custom way. The solution might be to proxy the default setTimeout/setInterval and the related clearTimeout/clearInterval to take note of currently running background tasks and wait until they are all finished. Should be doable, methinks. Not pretty, but doable. |
Something like this (same for intervals):
Of course, the Wait for the timeouts array to be empty should also have a default timeout (configurable)… Although it is possible to take note of the actual timeout/interval times, it might not be such a good idea to start watching those, because, as a rule, it's just bad practice to leave timeouts/intervals uncleared: we can even help find those 😉 |
The other problem is that with HtmlUnit we could simply intercept any JS code to be processed and instrument that (eval, new Function, etc.), so that was rather simple. With WebDriver, however, this is not possible (not with any driver implementation other than HtmlUnit, anyway), so this is gonna get trickier. |
The timeout might be problematic. At least with jasmine you're probably fine as long as you don't use jasmine.Clock.useMock... However, you might be able to extend and override [executeScript]( reference for idea to modify the script as needed. Really would be nicer to have a 'beforeScript' built into RemoteWebDriver. |
@kc0dhb it would be nice if the listener was actually running in the browser. However, it's only about the JS that you send to the browser using the driver (actually, the last comment in the same thread mentions the same use case), so, as far as I can tell, I can't use it. There is no access to the underlying JavaScript engine, only the HtmlUnitDriver would allow that. So far, I've built a simple prototype that does what I mentioned above – runs the webdriver through a proxy and instruments the loaded .js files. This works, but there are two problems:
So far, dynamically compiled code was never a problem, since HtmlUnit provides hooks into its own JS engine, so you can do a lot of things (like instrument the code). Now, with any other driver it becomes nigh impossible – and it's okay, I can always leave the support for instrumenting dynamically compiled code with the HtmlUnitDriver and the users of all the others will have to understand that they gain some, lose some. In most cases, I guess, such a level of instrumentation is not required, and will be just noise. |
- can only generate coverage for files loaded via HTTP - the URL to the server serving the tests (baseDir) cannot be localhost or 127.0.0.1, otherwise the request coming from PhantomJS is not proxied and no instrumentation can happen (even when serving from localhost, have to use any other interface besides loopback) - no instrumentation for dynamically compiled code (evals, new Function(), strings being passed to setTimeout/setInterval) - major refactoring, including using HtmlUnit's WebClient via HtmlWebDriver
I'll copy the commit message just as a reference:
I'd be very grateful if anyone could try this before I release it, something like:
To be honest, this is a bit of a nightmare: feels like too much work for something, as far as I can tell, not that important. Unit tests are supposed to be browser-agnostic, IMHO, and HtmlUnit should be enough for 99.9% of cases. |
No description provided.
The text was updated successfully, but these errors were encountered: