-
Notifications
You must be signed in to change notification settings - Fork 80
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
Conversation
replace this with handling many smaller snapshots
web/client-api/src/main/java/io/deephaven/web/client/api/JsColumnStatistics.java
Outdated
Show resolved
Hide resolved
web/client-api/src/main/java/io/deephaven/web/client/api/WorkerConnection.java
Outdated
Show resolved
Hide resolved
...client-api/src/main/java/io/deephaven/web/client/api/subscription/SubscriptionTableData.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this 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 UnableToCompleteException
s 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
task.awaitStatusTimeout.set 120 | ||
task.checkInterval.set 100 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
web/client-api/src/test/java/io/deephaven/web/client/api/AbstractAsyncGwtTestCase.java
Outdated
Show resolved
Hide resolved
web/client-api/src/test/java/io/deephaven/web/client/api/AbstractAsyncGwtTestCase.java
Outdated
Show resolved
Hide resolved
web/client-api/src/test/java/io/deephaven/web/client/api/AbstractAsyncGwtTestCase.java
Outdated
Show resolved
Hide resolved
web/client-api/src/test/java/io/deephaven/web/client/api/AbstractAsyncGwtTestCase.java
Outdated
Show resolved
Hide resolved
web/client-api/src/test/java/io/deephaven/web/client/api/AbstractAsyncGwtTestCase.java
Outdated
Show resolved
Hide resolved
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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
- Increased connect timeout to 1s - Added some sugar to some of the timeouts so they're easier to identify
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works on Mac
web/client-api/src/test/java/io/deephaven/web/client/api/NullValueTestGwt.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Restores some unit and integration tests to run as part of the local/CI builds, as part of the
check
task.Partial #188