Add IT test for push in embedded web components

[denis-anisimov]

Fixes #5006

---

This change is 

[ujoni]

Reviewed 4 of 4 files at r1.
Reviewable status: 2 unresolved discussions, 0 of 1 LGTMs obtained (waiting on @denis-anisimov)

---

flow-tests/test-web-components/src/test/java/com/vaadin/flow/webcomponent/UpdateServerSideWebComponentIT.java, line 41 at r1 (raw file):

                updateCount < 50);

        waitUntil(driver -> getUpdateCount() > 25, 5);

Why wait for 25 and not for getUpdateCount() > updateCount? Test could be potentially less flake-y, and would remove the need for some of the other tests.

As a joke, I tried:

        for (int i = 0; i < 50; i++) {
            final int ii = i+1;
            waitUntil(driver -> {
                int count = getUpdateCount();
                return count > ii && count < ii + 10;
            }, 1);
        }

but that is not very readable.

---

flow-tests/test-web-components/src/test/java/com/vaadin/flow/webcomponent/UpdateServerSideWebComponentIT.java, line 58 at r1 (raw file):

        updateCount = getUpdateCount();
        Assert.assertTrue(

Could use assertEquals("The update count does not have maximum value", 50, updateCount);

[denis-anisimov]

Reviewable status: 2 unresolved discussions, 0 of 1 LGTMs obtained (waiting on @ujoni)

---

flow-tests/test-web-components/src/test/java/com/vaadin/flow/webcomponent/UpdateServerSideWebComponentIT.java, line 41 at r1 (raw file):

Previously, ujoni (Joni) wrote…

Why wait for 25 and not for getUpdateCount() > updateCount? Test could be potentially less flake-y, and would remove the need for some of the other tests.

As a joke, I tried:

        for (int i = 0; i < 50; i++) {
            final int ii = i+1;
            waitUntil(driver -> {
                int count = getUpdateCount();
                return count > ii && count < ii + 10;
            }, 1);
        }

but that is not very readable.

I'm not sure what you really suggest.
getUpdateCount() > updateCount is almost the same as I do here except that you are using the initial value updateCount instead of hardcoded 25.

I check that some initial value is less than maximum value (well, actually I should check that the initial value is quite small, preferably 0).
Then I check that the middle (25) is gone through .
And the maximum number is reached.

Which scenario do you suggest ?

---

flow-tests/test-web-components/src/test/java/com/vaadin/flow/webcomponent/UpdateServerSideWebComponentIT.java, line 58 at r1 (raw file):

Previously, ujoni (Joni) wrote…

Could use assertEquals("The update count does not have maximum value", 50, updateCount);

Done.

[denis-anisimov]

Reviewable status: 2 unresolved discussions, 0 of 1 LGTMs obtained (waiting on @ujoni)

---

flow-tests/test-web-components/src/test/java/com/vaadin/flow/webcomponent/UpdateServerSideWebComponentIT.java, line 41 at r1 (raw file):

Previously, denis-anisimov (Denis) wrote…

I'm not sure what you really suggest.
getUpdateCount() > updateCount is almost the same as I do here except that you are using the initial value updateCount instead of hardcoded 25.

I check that some initial value is less than maximum value (well, actually I should check that the initial value is quite small, preferably 0).
Then I check that the middle (25) is gone through .
And the maximum number is reached.

Which scenario do you suggest ?

Alright, now I think I understood your point: if use waitUntil(driver -> getUpdateCount() >updateCount) then one assertion is not needed.

I'm not sure that this approach is really better but it really reduce the number of checks.
Let it be so.

[ujoni]

Reviewed 1 of 1 files at r2.
Reviewable status: complete! all discussions resolved, 1 of 1 LGTMs obtained