Selenium WebDriver: In welchem ​​Umfang kann ich auf JavaScript zurückgreifen?

Question

Ich entwickle eine Bibliothek, die Selenium 2 mit einigen benutzerdefinierten Befehlen erweitert. Die Bibliothek sollte sowohl von Seleniums Java und Python Bindings als auch in Selenium IDE verwendbar sein. Von meiner research sollten diese drei Zielbindungen mindestens 80% aller Selenium 2-Skripte abdecken.

Um meine benutzerdefinierten Befehle für Selenium IDE zu implementieren, denke ich, ich muss ein Plugin dafür in JavaScript schreiben.

Meine Frage ist diese: Wenn ich bereits eine Implementierung meiner benutzerdefinierten Befehle in JavaScript habe, ist es sicher, diese Implementierung für die Java-und Python-Bindungen meiner Bibliothek zu verwenden?

Ich denke an einen Ansatz, der die JavaScript-Implementierung meiner Befehle über WebDriver#executeScript injiziert. Hier ist eine Pseudocode-Implementierung von dem, woran ich denke.

In Java:

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

In code.js:

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

Also, zu meinen benutzerdefinierten Befehl fooJava() in Java ausführen, code.js meine Bibliothek würden in den Browser über executeScript injiziert werden. Dies würde eine JavaScript Implementierung von foo, sagen fooJavaScript enthalten. In einem nächsten executeScript Anruf würde dann dieser fooJavaScript aufgerufen werden.

Während dieser Ansatz mich mit verhindern würde meine Gewohnheit implementieren Befehle dreimal (Java, Python, Selenium IDE), ich habe ein paar Bedenken:

1. Wenn ich spritze meine code.js, bin ich in Gefahr den globalen Zustand der Website zu zerstören?
2. In welchem ​​Umfang kann ich auf JavaScript zurückgreifen? Funktioniert es, wenn ein Alarmdialog vorhanden ist? In der Praxis, wie viele der Treiber, die mit Selenium verwendet werden, unterstützen nicht JavaScript? Z.B. HtmlUnit?
3. Funktioniert das in allen gängigen Browsern (etwas neuere Versionen von IE, Chrome, Firefox, Safari)?

Ihre realen Erfahrungen damit würden sehr geschätzt werden.

Answer 1

Prinzip besagt, dass Sie JS nicht als Testmechanismus verwenden sollten, wenn Sie nur eine Payload mit WebDriver bereitstellen.

WebDriver = Integrationstests
JS = wenn Sie Einheit

testet wollen, weiß ich nicht Ihre Anwendungsfälle genau, aber:

Wenn Sie versuchen, mit Integrationstests, Stick laufen WebDriver, um die Benutzerinteraktion am besten zu simulieren. Sie vermeiden auch browserübergreifende JS-Probleme in der Zukunft, indem Sie sich auf die WebDriver-Hooks verlassen, um mit der Seite zu interagieren, so dass Sie sich besser auf die Community verlassen, um zuverlässige grundlegende DOM-Interaktions-APIs für jeden Browser bereitzustellen.Wenn Sie keine Testbedingungen mit Browser-Interaktionen auslösen können, gelangen Sie in das Unit-/Code-Testgebiet statt in den Integrationstest.

Wenn Sie versuchen, den JS auszuführen, um im Wesentlichen eine einzelne Funktion oder einen Codeabschnitt anstelle einer integrierten Interaktion zu testen, versuchen Sie, einen Komponententest auszuführen. Komponententests werden am besten in JS mit etwas wie Jasmine durchgeführt (nennen Sie hier ein Framework).

Reasoning:
Integrationstests geschrieben werden sollen als Implementierung unabhängig wie möglich zu sein. Sie sollten keinen Funktionsnamen kennen, um einen Integrationstest auszulösen, da jemand den Funktionsnamen in der Zukunft ändern oder den Code neu strukturieren könnte.
Da Sie eine QE/Tester-Rolle ausfüllen, möchten Sie nicht dafür verantwortlich sein, Integrationstests zu unterbrechen, wenn sich der Code ändert - wenn Sie dies verwenden und verantwortlich sind, müssen Sie bei jeder Codeumstrukturierung einen Test ändern .

Quellen: Erfahrung als QE in mehr als 10.000 Mitarbeiter Software co.