Selenium WebDriver: To which extent can I rely on JavaScript?

Question

I am developing a library that extends Selenium 2 with some custom commands. The library should be usable from Selenium's Java and Python bindings as well as in Selenium IDE. From my research, these three target bindings should cover at least 80% of all Selenium 2 scripts.

In order to implement my custom commands for Selenium IDE, I think I need to write a plugin for it in JavaScript.

My question is this: If I already have an implementation of my custom commands in JavaScript, is it safe to re-use this implementation for the Java- and Python bindings of my library?

I am thinking of an approach that injects the JavaScript implementation of my commands via WebDriver#executeScript. Here is a pseudocode implementation of what I am thinking of.

In Java:

public void fooJava() {
    executeScript("Inject code.js");
    executeScript("fooJavaScript();");
}

In code.js:

function fooJavaScript() {
    // Implementation of command "foo" from Selenium IDE plugin.
}

So, to execute my custom command fooJava() in Java, my library's code.js would be injected into the browser via executeScript. This would contain a JavaScript implementation of foo, say fooJavaScript. In a next executeScript call, this fooJavaScript would then be called.

While this approach would prevent me from having to implement my custom commands three times (Java, Python, Selenium IDE), I have a few concerns:

1. When I inject my code.js, am I in danger of destroying global state of the web site?
2. To which extent can I rely on JavaScript? Will it work if an alert dialog is present? In practice, how many of the drivers used with Selenium do not support JavaScript? Eg. HtmlUnit?
3. Will this work in all major browsers (somewhat recent versions of IE, Chrome, Firefox, Safari)?

Your real-life experiences with this would be much appreciated.

Answer 1

Principle states you should not be using JS as your testing mechanism if you are just delivering a payload with WebDriver.

WebDriver = integration tests
JS = if you want unit tests

I don't know your use cases exactly, but:

If you're trying to run integration tests, stick with WebDriver to best simulate user interaction. You also avoid cross-browser JS issues in the future by relying on the WebDriver hooks to interact with the page, as in, you are better off relying on the community to provide reliable basic DOM interaction APIs for each browser. If you can't trigger test conditions with browser interactions, you're getting into unit/code testing territory instead of integration testing.

If you are trying to run the JS for sake of essentially testing a single function or piece of code rather than an integrated interaction, you are trying to run a unit test. Unit tests are best done in JS with something like Jasmine (name any framework here).

Reasoning:
Integration tests should be written to be as implementation independent as possible. You should not need to know a function name to trigger an integration test, since someone might change the function name in the future or restructure the code.
Since you are filling a QE/tester role, you do not want to be responsible for breaking integration tests when code changes - if you use this and are responsible, then you will need to change a test every time there is a code restructure.

Sources: Experience as a QE in 10,000+ employee software co.