Skip to content
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

Run JS API unit tests and integration tests in the Gradle build #4988

Merged
merged 32 commits into from
Jan 17, 2024

Conversation

niloc132
Copy link
Member

Restores some unit and integration tests to run as part of the local/CI builds, as part of the check task.

Partial #188

@niloc132 niloc132 marked this pull request as ready for review December 28, 2023 01:01
Copy link
Member

@mofojed mofojed left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should include instructions on how to run these tests as well. I ran ./gradlew gwtUnitTest and that worked correctly. Then I tried running ./gradle gwtIntegrationTest and it's just giving me a bunch of UnableToCompleteExceptions for each test:

> Task :web-client-api:gwtIntegrationTest FAILED
1 compiler directives added

io.deephaven.web.ClientIntegrationTestSuite > io.deephaven.web.client.api.subscription.ViewportTestGwt.testViewportOnUpdatingTable FAILED
    com.google.gwt.junit.JUnitFatalLaunchException at JUnitShell.java:708

io.deephaven.web.ClientIntegrationTestSuite > io.deephaven.web.client.api.subscription.ViewportTestGwt.testViewportSubsetOfColumns FAILED
    com.google.gwt.core.ext.UnableToCompleteException at JUnitShell.java:1334

io.deephaven.web.ClientIntegrationTestSuite > io.deephaven.web.client.api.subscription.ViewportTestGwt.testViewportWithNoInitialItems FAILED
    com.google.gwt.core.ext.UnableToCompleteException at JUnitShell.java:1334

web/client-api/client-api.gradle Outdated Show resolved Hide resolved
Comment on lines +115 to +116
task.awaitStatusTimeout.set 120
task.checkInterval.set 100
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Side note - really confusing that awaitStatusTimeout is in seconds, and checkInterval is in ms.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed... can go back and rewrite those, but I vote not today. This is code taken from the upstream docker-gradle plugin, and we didn't customize it further.

}

// start a grpc-api server
String randomSuffix = UUID.randomUUID().toString();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we doing this? Is this safe to do? Seems like this would mess up gradle caching?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would yes, but we are doing this all over for naming docker containers, so that you don't accidentally collide in parallel runs, or separate checkouts, etc. Since this is just for tests, we're not concerned with "oh these tests passed last time, so I'm not even going to run them this time" for integration tests.

String[] actual = Js.uncheckedCast(getColumnData(viewportData, column.apply(table)));
assertTrue("Expected " + Arrays.toString(expected) + ", found " + Arrays.toString(actual) + " in table "
+ table + " at state " + table.state(), Arrays.equals(expected, actual));
}, 2000);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Define as constant - same timeout is used in the other assertNextViewportIs method.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I want them to be different-ish constants, so you can nail down which timeout failed, since it can be a pain to find them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup that's fair too, though would be nice to define a base constant and just add an offset for uniqueness

for (int i = 0; i < code.size(); i++) {
final int index = i;
result = result.then(ignore -> {
delayTestFinish(4000 + index);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Constant? Unsure why 4000 was selected.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that running python on a brand new server in docker can sometimes be a little slow out of the gate, so I have a "large" timeout here.

It could make sense to change the strategy entirely and just have a per-test timeout instead, and set it to a few minutes - but it is nice to fail within a few seconds of the failing operation (as we don't have event handlers for all failures, we just let timeouts expire).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea that's all fine and good, just as a constant you can have those details as a comment so it's clear why you want a timeout of a 4s instead of say 40s or 400ms

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of these timeouts are "worst case, sometimes the browser or dh api lags a bit, here's a reasonably sized timeout that likely can't be exceeded in reasonable circumstances". 40ms definitely isn't good enough (browser GC could kill that alone), 400ms probably isn't enough either.

We could just say "every test should take less than 5 minutes" and not worry about each operation, but historically this has made it easier to figure out which specific operation is stuck/failing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right - that all makes sense, now add that "why" information as a comment on that timeout.

mofojed and others added 2 commits January 3, 2024 11:48
- Increased connect timeout to 1s
- Added some sugar to some of the timeouts so they're easier to identify
mofojed
mofojed previously approved these changes Jan 3, 2024
Copy link
Member

@mofojed mofojed left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works on Mac

Copy link
Member

@devinrsmith devinrsmith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Talking about selenium port and direct docker IP offline.

@@ -0,0 +1,3 @@
io.deephaven.project.ProjectType=DOCKER_REGISTRY
deephaven.registry.imageName=selenium/standalone-firefox:4.16.1-20231219
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of the other imageName are more open-ended so that the imageId can be bumped w/ bumpImage task. Is there a reason this tag was chosen?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Selenium client has historically been firmly tied to a single release of the browser+driver version, so it rarely will work to update this to "latest" without finding out what version that happens to be, and then update the test dependencies to match that specific version. This way, the version number is clear in both places.

mofojed
mofojed previously approved these changes Jan 3, 2024
@niloc132 niloc132 merged commit e7af7a1 into deephaven:main Jan 17, 2024
19 checks passed
@github-actions github-actions bot locked and limited conversation to collaborators Jan 17, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants