Remove the special constructor for selenium tests

[josefd8]

Currently, when you want your selenium tests to be executed in all the connected nodes in a selenium grid, you have to include a special constructor in the runner class, something like this:

public class CucumberMobileIT extends BaseTest {

    @Factory(dataProviderClass = BrowsersDataProvider.class, dataProvider = "availableMobileBrowsers")
    public CucumberMobileIT(String browser) {
        this.browser = browser;
    }
}

This constructor executes a small sub-routine, that connects to the web page of the selenium grid, and parse all the nodes and their capabilities from the HTML page. Then, the runner class is executed as many times as nodes are connected.

This is an interesting hack, however, there's a couple of issues with this that make me consider that is not a good idea to continue supporting it:

• The structure of the runner classes for selenium tests ends up being different. So, if you want to have selenium + rest tests, you need to place your selenium tests in a separate runner class.
• Maybe the most important factor: in the newest versions of selenium grid, the console page (where you see all connected nodes), is completely different. This means we cannot get the list of connected pages and their capabilities anymore by just parsing the HTML. This means that this functionality will only work with older versions of selenium grid
• The functionality is complicated to maintain and debug
• Lack of paralelism: There's no way to execute the tests in all the browsers at the same time (in parallel) using this approach. Only one by one. UI tests are usually the longest ones....

However, we would be losing the possibility of executing the tests in all connected nodes. There's is no easy way of fixing this problem. My idea is to use an approach similar to the karate framework

https://github.com/intuit/karate/tree/master/karate-core#driver

That is, when a user executes a selenium test with the @web annotation, ginger will try to create a default driver (local chrome for example), but the user could also configure the initialization of the driver and its capabilities using a gherkin step. If we combine this with a scenario outline, we could achieve parallel execution of the test in the connected nodes (since testNG allows parallel execution in scenario outlines).

@oleksandr0001

[oleksandr0001]

I don't see other option, it is needed to support the new Selenium versions. I think it's good solution (using the Step to initialize a driver for those complex cases).
It is necessary to think details how to implement the parallelism of different capabilities (test in different browsers at the same time) with testNG.