Visual testing API

[nadvolod]

This is PR designed to iron out the visual API. Once we agree on it we can work on making it happen.
Here is a real world example of a current usage of Screener for visual testing https://github.com/saucelabs-training/demo-java/blob/master/java8/visual-e2e/visuale2e.junit4.examples/src/test/java/com/saucedemo/VisualCrossPlatformTests.java

[nadvolod]

Here is an overview of what got changed by this pull request:

Issues
======
- Added 8
           

Complexity increasing per file
==============================
- java/src/main/java/com/saucelabs/saucebindings/visual/SauceVisualOptions.java  4
- java/src/test/java/com/saucelabs/saucebindings/integration/VisualE2ETest.java  1
- java/src/test/java/com/saucelabs/saucebindings/SauceVisualSession.java  3
         

See the complete overview on Codacy

[nadvolod]

Codacy found an issue: Perhaps 'viewportSize' could be replaced by a local variable.

[nadvolod]

Codacy found an issue: Avoid unused private fields such as 'visualProjectName'.

[nadvolod]

Codacy found an issue: Avoid unused private fields such as 'viewportSize'.

[nadvolod]

Codacy found an issue: Perhaps 'visualCapabilities' could be replaced by a local variable.

[nadvolod]

Codacy found an issue: Fields should be declared at the top of the class, before any method declarations, constructors, initializers or inner classes.

[nadvolod]

Codacy found an issue: Avoid unused imports such as 'lombok.var'

[nadvolod]

Codacy found an issue: Perhaps 'visualProjectName' could be replaced by a local variable.

[nadvolod]

Codacy found an issue: Avoid unused imports such as 'lombok.var'

[titusfortner]

Should we have a separate session class for Visual?

We could do something as simple as:

SauceOptions options = new SauceOptions();
options.setVisual();

SauceSession session = new SauceSession(options);

We don't necessarily need a VisualOptions class either:

SauceOptions options = new SauceOptions();
options.setName("visualProjectName");
options.setScreenResolution("1280x1024") // same as viewportSize

We could even use a takeScreenshot() method that would work for normal Sauce sessions

session.takeScreenshot("Snapshot name");

[nadvolod]

@titusfortner I really like your approach. It's certainly cleaner. I went to separate classes because it seemed like that's the same direction we were going in mobile. So I tried to keep it similar. Regardless, I do want to iron out the use case below. To me, there is ambiguity when using/re-using methods because it means that they will have different behavior depending on whether you are using functional or visual, potentially breaking SRP.

    public void withVisualOptions() {
        SauceOptions options = new SauceOptions();
        //This becomes a mandatory call in order to start calling the methods below,
        //otherwise they become useless/confusing methods?
        options.setVisual();

        // is it clear that setProjectName only applies to Sauce Visual and not to Functional?
        options.setProjectName("Sauce Bindings");

        // how do we know that this is for visual?
        options.setViewportSize("1280x1024");

        var visualSession = new SauceSession(visualOptions);

        //Not sure if you always need to set test name,
        //but if we do then maybe we can just do start(testName);
        visualSession.start();

        visualSession.setTestName("Visual Test");

        //Same thing here, do we want ambiguity between visual and functional so that when we call this method,
        // users might be confused about why the snapshot isn't happening in their functional test
        visualSession.takeSnapshot("Snapshot name 1");

        Boolean isPassed = visualSession.stop();
        assertTrue(isPassed);
    }

This seems like a blend of both and solves the ambiguity:

    public void withVisualOptions() {
        SauceOptions options = new SauceOptions();
        options.setVisual();
        options.visual.setProjectName("Sauce Bindings");
        options.visual.setViewportSize("1280x1024");

[titusfortner]

Superceded by #256