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
Start converting tests to Playwright #307
Conversation
web/tests/lynxkite.ts
Outdated
@@ -0,0 +1,1596 @@ | |||
import { expect, Locator, Page } from '@playwright/test'; |
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.
This file is a garbage dump at the moment. It started as a copy of web/test/test-lib.js
, then I converted the parts that I used to Playwright.
I think in many places this library is overdoing it. Is expectDirectoryNotListed(name)
any clearer than expect(page.splash.directory(name)).not.toBeVisible()
?
My approach would be to convert the tests fairly faithfully in the first round. Then we can have another pass to clean up a bit.
web/tests/splash.spec.ts
Outdated
return page; | ||
} | ||
|
||
test.describe.configure({ mode: 'serial' }); |
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.
The Protractor tests have an intricate test framework implemented in web/test/declarative.js
. Instead of a simple independent/serial execution this allows a tree of tests, where some tests preserve the state and some tests change it.
This is made possible by the discardAllReallyIMeanIt
endpoint, which resets LynxKite completely and provides a safe starting state. I'm not fond of this, because I often have some nice workspaces for testing stuff I'm working on, and then the tests blow it away.
My hope is that we can ditch all this. We can get to a known state by (re)creating a directory for the tests. We can write each test file to be runnable on its own. They can still share code: another test could import newSplash()
from this file and just call it. We don't need to build a framework for this.
If we put the test stuff for each test file into a separate LynxKite directory, perhaps we could one day run those in parallel. But it's fine not to worry about this for now.
On my laptop when I run all the tests, something goes wrong when "SQL runs nice on belongs to reached from project and segmentation" tries to add the "Create vertices" box. It clicks on it but the popup doesn't come up. I think this may be an actual LynxKite bug. A difference between Protractor and Playwright is that Protractor waited for network requests to finish before taking the next action. Playwright doesn't care. So it may be clicking the box before the |
It passed on GitHub Actions. I guess let's merge it! (After review.) Then we can start converting more tests and fixing things as we go. |
web/tests/sql.spec.ts
Outdated
await tableBrowser.expectNode([3, 1], 'age (Double)', '`age`'); | ||
}); | ||
|
||
/* |
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.
These are commented-out in the original. But let's fix what we can and delete what we no longer need during this migration.
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.
These are commented-out in the original. But let's fix what we can and delete what we no longer need during this migration.
I've reviewed them. Nothing worth fixing I think. I've deleted them all.
852dd07
to
d1d78df
Compare
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.
I've managed to track down some reliability issues. Looks rock solid for me now!
web/tests/sql.spec.ts
Outdated
await tableBrowser.expectNode([3, 1], 'age (Double)', '`age`'); | ||
}); | ||
|
||
/* |
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.
These are commented-out in the original. But let's fix what we can and delete what we no longer need during this migration.
I've reviewed them. Nothing worth fixing I think. I've deleted them all.
{ logicalX: boxData.x, logicalY: boxData.y }, | ||
{ boxId: boxData.id }); | ||
}, boxData); | ||
// Wait for the backend to save this box. |
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.
Alternatively we could make it so that it's okay to click a box before it's saved. I've filed #308.
00c6004
to
a0d1d99
Compare
a0d1d99
to
03b1571
Compare
@@ -33,13 +34,14 @@ jobs: | |||
fi | |||
git checkout -b "$branch" || true | |||
- name: Download latest earthly | |||
run: "sudo /bin/sh -c 'wget https://github.com/earthly/earthly/releases/download/v0.6.26/earthly-linux-amd64 -O /usr/local/bin/earthly && chmod +x /usr/local/bin/earthly'" | |||
run: "sudo /bin/sh -c 'wget https://github.com/earthly/earthly/releases/download/v0.6.30/earthly-linux-amd64 -O /usr/local/bin/earthly && chmod +x /usr/local/bin/earthly'" |
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 can't we use /earthly/releases/latest/...?
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 can't we use /earthly/releases/latest/...?
With a fixed version the behavior is more predictable. With /latest
there would always be a chance that something broke because of a new Earthly release.
(I'm in favor of a lockfile for the Conda dependencies too, for the same reason.)
But maybe we can switch to /latest
when Earthly becomes stable enough, e.g. 1.0.
@@ -1,4 +1,4 @@ | |||
VERSION --use-copy-include-patterns 0.6 | |||
VERSION --use-copy-include-patterns --try 0.6 |
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.
Cannot find this option at docs.earthly.dev. What does it do?
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.
Cannot find this option at docs.earthly.dev. What does it do?
Yeah, it's pretty new. See earthly/earthly#587 (comment).
Unfortunately it only works for files under 64 kB at the moment. (earthly/earthly#2452) We will only start getting test reports when a new Earthly is released with the fix.
@@ -25,24 +25,24 @@ sbt-deps: | |||
|
|||
npm-deps: | |||
COPY web/package.json web/yarn.lock web/ | |||
RUN cd web; yarn --frozen-lockfile | |||
RUN cd web && yarn --frozen-lockfile |
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.
Good idea!
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.
Good idea!
For cd
it doesn't make much difference. But I used ;
instead of &&
at some other step and ended up ignoring a failure as a result. I took revenge on all semicolons.
KITE_DEPLOYMENT_CONFIG_DIR=$(realpath "${KITE_DEPLOYMENT_CONFIG_DIR}") | ||
export HTTP_PORT=$[ 9100 + RANDOM % 100 ] | ||
export HTTPS_PORT=$[ 9200 + RANDOM % 100 ] | ||
export KITE_HTTP_PORT=$[ 9100 + RANDOM % 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.
Why did we need to make these ports random at the first place?
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 did we need to make these ports random at the first place?
I think it's to make it more convenient for local testing. You usually run a LynxKite on port 2200 that you're working with. You can use that for testing. This script is for starting a different, brand new LynxKite just for the test.
For testing in Earthly it doesn't matter. A fixed port would be fine.
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.
Thanks!
I was considering whether to merge this before the release. I think it's fine. The |
First step for #238. Includes a conversion of
web/test/tests/splash-page-test.js
.I haven't updated the docs yet. You can see the CI setup in the Earthfile. For local development you install Playwright the same way. Then you run LynxKite with
run.sh
and run the tests withyarn playwright test
. There's a nice debug utility you can start withyarn playwright debug
. If you hit an issue that you can't reproduce withdebug
, you can run the tests withyarn playwright test --trace on
. This will save a trace that you can replay to see what happened.I want to set up the trace on GitHub Actions too. The trace will have to be saved as an Earthly local artifact, then saved as a GitHub Actions artifact. This will be fantastic to track down any flaky tests. Or maybe we just won't have flaky tests at all!