-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Each TestBench command for a Fusion app takes 20s with Flow 6 alpha 5 #9905
Comments
Both those features are active even if not using any Flow views, so it would be logical that they would be in the |
Would be nice to have a smoketest in Flow that checks that the wait the TB test execution start doesn't take too long for any Vaadin app. |
The wait for Vaadin script in TestBench is like this:
And after moving |
The problem was that, in the TS only version, the rendered elements are being created in the shadow root and then statements like By downloading a simple application from @Test
public void testHelloWorldView_enterNameAndClickSayHello_notificationShouldBePresentedWithProperValue() {
getDriver().get("http://localhost:8080/hello");
waitUntil(driver -> $("hello-world-view").first() != null);
TestBenchElement helloWorldView = $("hello-world-view").first();
helloWorldView.$(TextFieldElement.class).id("name-field").setValue("World!");
helloWorldView.$(ButtonElement.class).first().click();
waitUntil(driver -> findElement(By.tagName("vaadin-notification-card")).isDisplayed());
Assert.assertEquals("Hello World!", findElement(By.tagName("vaadin-notification-card")).getText());
} So I'm closing this issue as I could not see a bug in regard with using TestBench with flow and tested them in both TS only and also in Java only for Flow |
One the points of TB is to not have to figure out what you need to know / do to be able to write the UI tests with Vaadin. So to make sure I've understood correctly, if one comments the following line the test above:
Then the test will fail with
but there is no 20 second wait happening for the test to start executing ? |
That That example is not about how a test should be written for TS only applications using TestBench, and it is more of a quick test to show that No such wait (20 sec. or so) happened during smoke test. Having the application up and running, it takes 2-3 sec to execute the above test (including checking the proKey license, opening the browser, etc.). |
Right, thanks. So there is no additional disclaimer that should be needed for testing Fusion apps for now. |
Was this issue fixed or just closed? When you tested this, did you remove the Flow part from Test project: https://github.com/Artur-/test-fusion-testbench It should not say
rather it should say something like
|
No, as I mentioned in the above, I couldn't see any timeout problems with the TS only app I downloaded from |
I'm making some changes to fix the issue, but even before that, I can say I didn't find a way for running that IT using |
There is no waiting for frontend compilation when you are running with |
TestBench wait logic is based the existence of Flow object and in Fusion Only apps Flow object should not be initialized. moving _vaadintheme_something and devModeGizmo to Vaadin namespace fixes the TB wait logic in Fusion Only apps. Fixes: #9905
…#10014) (#10016) TestBench wait logic is based the existence of Flow object and in Fusion Only apps Flow object should not be initialized. moving _vaadintheme_something and devModeGizmo to Vaadin namespace fixes the TB wait logic in Fusion Only apps. Fixes: #9905 Co-authored-by: Soroosh Taefi <taefi.soroosh@gmail.com>
Description of the bug / feature
The waiting logic in TestBench goes partly like
This no longer works at all in Fusion apps with Flow 6 alpha 5 because the application theme is set as
apparently also the DevModeGizmo is set in dev mode as
The result is that each and every command in a test takes 20s, which is the timeout for waiting
Not sure if this should be fixed in Flow or TestBench
The text was updated successfully, but these errors were encountered: