Consider improving JavaScript workarounds

[craigfowler]

Background

In a number of places it has become apparent that browsers and/or web drivers have bugs which mean that normal interactions don't work as they would be expected.

Just looking at the browser flags shows where this is the case.

Often, there is a JavaScript-based workaround available for the action which the web driver would otherwise perform. One such workaround is currently in use for setting date values (some browsers need to set it directly via script).

This workaround currently only works for an element selected by ID. However JavaScript has come some way and native selection by CSS selector is also possible.

This ticket

This ticket is to look into the feasibility of expanding upon that 'JavaScript workaround' concept into some kind of service which can provide workarounds to-order. The outcome would be a feasibility assessment as well as a rough architectural plan to implement it.

Notes so far

Workarounds are expected to be based upon:

• Workaround name
  • Each workaround would have a name by which it is registered
  • Those names would actually be related to a concrete type which provides that workaround, so actually it wouldn't use a string name, but rather a type name
• Web element adapter (target element)
• Browse the web ability (web driver)

Indeed, the signature of a workaround may well be very similar to the signature of a performable. It might be that I can use the base performable interfaces as the base type for these.

What I expect is a factory which creates the workaround instances, assembling JavaScript from a number of snippets stored in the application. This would return an instance of a type which executes that workaround on the browser.

[craigfowler]

A benefit of this is that numerous currently-ignored tests (actions which are unsupported due to web driver issues) could be supported once again via workarounds.

[craigfowler]

The workarounds I may need to create via this mechanism:

• Drive an HTML select element (change its state, mirroring the SelectElement class)

• Deal with locale format for HTML 5 date elements

• Clear the value of an HTML 5 date fields

[craigfowler]

This looks like a promising technology, as it will allow me to use CSS selectors to find elements.

https://developer.mozilla.org/en-US/docs/Web/API/Element/querySelectorAll

[craigfowler]

It is actually possible to pass web elements directly into the scripts as parameters. So - actually the part of the script in which we identify one or more target elements is easier than previously believed.

[craigfowler]

Development plan

The architectural goals of this work are:

• The JavaScript should be testable via a standalone Jasmine runner, assuming some sort of test harness is in place
• From the C# end of things, everything must be strongly typed

C# code

On the C# end of things, what I need is a generalised way of executing canned scripts and getting the results. The actions are a good start but I would like an additional pair of actions which operate upon an object instance that represents a canned script.

The actions would hold that 'script object' as a private field (passed in as a constructor parameter). The arguments to that script would work just like the normal JavaScript actions.

Stored scripts

A stored script will be a type which has an embedded resource associated. Actually it won't need to be an embedded resource, as long as the implementation can get the script is fine.

Those script objects must implement this interface:

public interface IStoredScript
{
    string GetScript();
    string GetEntryPointName();
}

The responsibility of that object is to get the script resource, and the name of its entry-point function.

Stored script actions

Stored script actions will work just the same as current actions, except that they will get their script from a stored script instance.

They will need an instance of a Stored script runner in order to make the script executable.

Stored script tasks

Tasks should be written which wrap this all up into a simple reusable operation.

The task would be responsible for:

• Instantiating the appropriate stored script type
• Gathering the parameters for the script, from recognisable strong types
• Instantiating the action (passing the script and the params as an object array)
• Invoking the action

Stored script runner

This will be a quite a simple type which receives a stored script and constructs a runnable piece of JavaScript by appending the entry point name to the main script body.

This will produce something that looks like:

function myEntryPoint(argsArray)
{
    // Implementation omitted
}
return myEntryPoint(arguments);

This can then be executed with an array of parameters and the JavaScript WebDriver.

JavaScript

All JavaScript must produce a single function which serves as the entry point. The name of that entry point must be recorded in the GetEntryPointName method.

The script must not be self-executing, it must rely upon an invocation which the script will not provide itself.

Test harness

Each stored script type will potentially have a test suite. This will be executed via a test harness which:

1. Gets the type name of the stored script object
2. Executes a controller action which runs that script and it's tests
   • Test JavaScript will be named after the script type name, with an extension
3. Verifies that the JavaScript test framework reported a success