Stabilize the SelenideAddonsTest

[occupant23]

The problem of issue #125 occurred again.
Find a way to work in both situations GDPR overlay visible or not.

[oomelianchuk]

The test is still unstable on my machine. The tests testDownwardDragAndDrop, testUpwardDragAndDrop, testDownwardDragAndDropUntilCondition and testUpwardDragAndDropUntilCondition failed while the test run. As I added the slider.scrollIntoView(true); line for downward tests and the slider.scrollIntoView(true); slider.scrollIntoView(false); lines for the upward tests, the test seemed to stabilize. Please check, if these lines provoke any failures on your machine and if they don't, add them to the tests.

[oomelianchuk]

Wouldn't it be helpful for the future debugging of the test, to add some asserts about the slider state before interactions, like this?

    @Test()
    public void testLeftwardDragAndDrop()
    {
        openSliderPage();
        SelenideElement slider = $(".balSlider a[role=slider]");
        Assert.assertEquals("-10", slider.getAttribute("aria-valuenow"));
        SelenideAddons.dragAndDrop(slider, -32, 0);
        Assert.assertEquals("-2", slider.getAttribute("aria-valuenow"));
    }

[oomelianchuk]

Should we prefer the JUnit assertions or Selenide assertions for the slider value check? On the one hand, the JUnit assertion has a clearer error message and doesn't contain any (useless?) information about the slider element. On the other hand, Selenide provides implicit wait e.g. for the case of slow internet connection. What do you think?

[oomelianchuk]

Why do you use waitUntil with the Neodymium.configuration().selenideTimeout() value, isn't this the same as simply shouldBe(hidden) ?

[oomelianchuk]

I noticed, that the code like this

        try
        {
            $("#onetrust-accept-btn-handler").shouldBe(visible);
        }
        catch (ElementNotFound e)
        {
            overlayIsVisible = false;
        }

is/can be used in multiple projects, e.g. I built a custom method like this for the cardfactory project. Wouldn't it be a good idea to extend SelenideAddons with methods to wait until or while some condition, without any exception throwing but just returning a boolean value as information whether the condition was fulfilled?

[occupant23]

The test is still unstable on my machine. The tests testDownwardDragAndDrop, testUpwardDragAndDrop, testDownwardDragAndDropUntilCondition and testUpwardDragAndDropUntilCondition failed while the test run. As I added the slider.scrollIntoView(true); line for downward tests and the slider.scrollIntoView(true); slider.scrollIntoView(false); lines for the upward tests, the test seemed to stabilize. Please check, if these lines provoke any failures on your machine and if they don't, add them to the tests.

Can't be reproduced. Seems to be associated with changing test to not headless and the used display.

[occupant23]

Wouldn't it be helpful for the future debugging of the test, to add some asserts about the slider state before interactions, like this?

    @Test()
    public void testLeftwardDragAndDrop()
    {
        openSliderPage();
        SelenideElement slider = $(".balSlider a[role=slider]");
        Assert.assertEquals("-10", slider.getAttribute("aria-valuenow"));
        SelenideAddons.dragAndDrop(slider, -32, 0);
        Assert.assertEquals("-2", slider.getAttribute("aria-valuenow"));
    }

Good point, will be done.

[occupant23]

Should we prefer the JUnit assertions or Selenide assertions for the slider value check? On the one hand, the JUnit assertion has a clearer error message and doesn't contain any (useless?) information about the slider element. On the other hand, Selenide provides implicit wait e.g. for the case of slow internet connection. What do you think?

Will be changed to Selenide assertions since this is the preferred way. Good catch.

[occupant23]

Why do you use waitUntil with the Neodymium.configuration().selenideTimeout() value, isn't this the same as simply shouldBe(hidden) ?

I checked it. The functions are the same. I will adjust this.

[occupant23]

I noticed, that the code like this

        try
        {
            $("#onetrust-accept-btn-handler").shouldBe(visible);
        }
        catch (ElementNotFound e)
        {
            overlayIsVisible = false;
        }

is/can be used in multiple projects, e.g. I built a custom method like this for the cardfactory project. Wouldn't it be a good idea to extend SelenideAddons with methods to wait until or while some condition, without any exception throwing but just returning a boolean value as information whether the condition was fulfilled?

Created issue #148 for this.

[occupant23]

done can be rechecked again

[occupant23]

@oomelianchuk: Can be rechecked again.

[oomelianchuk]

In my opinion, the test is now good and clear. I have no more complaints :)