Draft Playwright test cases! #10
Conversation
ajhyndman
force-pushed
the
initial-test-cases
branch
2 times, most recently
from
026d7a9
to
cd05f32
Compare
| @@ -0,0 +1,2 @@ | |||
| /** Assert that a metric is triggered within +/- 200ms */ | |||
| export const FUDGE = 200; | |||
There was a problem hiding this comment.
Love the name of this constant 😁
There was a problem hiding this comment.
Yeah, haha. I'm not sure what the best way to assert expected TTVC values is. There's always going to be some intrinsic variability between test runs.
If this pattern makes sense, I think we could define a custom test matcher that asserts that something happens within a standard "fudge factor" of the expected time.
Another idea I had was maybe the .html source file should signal to the test process the point at which VC is expected to occur? I haven't worked out the logistics of that yet.
ajhyndman
force-pushed
the
initial-test-cases
branch
from
cd05f32
to
f5a4a00
Compare
ajhyndman
force-pushed
the
jest
branch
2 times, most recently
from
d078470
to
752c87d
Compare
ajhyndman
force-pushed
the
initial-test-cases
branch
from
f5a4a00
to
e0d4eff
Compare
ajhyndman
force-pushed
the
initial-test-cases
branch
from
335925c
to
0f153a0
Compare
| app.use('/dist', express.static(path.join(__dirname, '../../dist'))); | ||
| // allow loading libraries from node_modules | ||
| app.use('/node_modules', express.static(path.join(__dirname, '../../node_modules'))); |
There was a problem hiding this comment.
This is maybe a weird choice.
Maybe it's a mistake, but I thought I would try to draft a few actual React application test cases. I still don't want any tests to have to rely on a CI environment having access to the internet, so I added /node_modules to the set of express static paths.
This lets you use a script tag something like the following in a test case:
<script src="/node_modules/react/umd/react.production.min.js"></script>
|
@zubair-io I reorganized the playwright test cases into folders now! I think you're right, it will scale better.
|
|
I pushed another dozen test cases today! |
src/in_viewport_mutation_observer.ts
Outdated
| if (loadingImages.size === 0) { | ||
| return Promise.resolve(performance.now()); | ||
| } |
There was a problem hiding this comment.
I am pushing this fix in production as well. D:
https://phabricator.dropboxer.net/D848659
It's so hard to spot these bugs just by running the code directly against Dropbox.
|
I was running the tests and they seem to still be flaky while multi threaded. We should probably adress a good configuration for running the tests without being that flaky. |
|
I was testing and it seemed to work way more with only 3 workers without being painfully slow, maybe we could consider as setting that as the default? |
|
@Jonathan1600 Let's try that! |
ajhyndman
force-pushed
the
initial-test-cases
branch
from
7b4c8f1
to
5fd9a99
Compare
@Jonathan1600 and I brainstormed several tests cases:
https://www.dropbox.com/scl/fi/2stvse1i1tdl8slaonu1u/Visually-Complete-Calculator.paper?dl=0&rlkey=xxnmuv5rszhv65pvub7qs479w#:uid=883837026368011922165267&h2=End-to-end-Test-Cases
These are the first dozen of those test cases.