-
Notifications
You must be signed in to change notification settings - Fork 25
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
Jest spike #66
Jest spike #66
Conversation
test/index.ts
Outdated
}); | ||
}); | ||
export function visregSuite(browserName: string) { | ||
jasmine.DEFAULT_TIMEOUT_INTERVAL = 60e3; |
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.
Use 60000
instead of 60e3
. It's easier to grok.
test/chrome.ts
Outdated
@@ -0,0 +1,3 @@ | |||
import * as tests from "./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.
Seems index is more of a utility rather than an entry point. Perhaps we should rename index.ts
to something more appropriate. Which would also warrant a rename of the import alias.
test/package.json
Outdated
@@ -20,15 +18,24 @@ | |||
}, | |||
"scripts": { | |||
"build": "tsc", | |||
"build:visreg": "tsc bin/visreg.ts bin/visreg.config.ts --outdir built/bin --lib es6 && tsc", |
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.
Clean this up
test/package.json
Outdated
"webdriver": "npm run webdriver:update && npm run webdriver:start", | ||
"webdriver:update": "scripts/webdriver-update", | ||
"webdriver:start": "scripts/webdriver-start" | ||
}, | ||
"jest": { |
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.
Move this somewhere else.
test/util.ts
Outdated
@@ -31,6 +32,6 @@ export function $x( | |||
} | |||
|
|||
// "page object" |
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.
Document this better.
Future request: plug in tests into |
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.
Dev LGTM
@CITguy Made https://jira.rax.io/browse/SURF-703 to track the watch mode for functional tests. This will be much simpler with "proper" unit tests, which is a work in progress. |
@CITguy this is refactored and looking better. However, the more time I spend with jest the more convinced I am that it won't make sense to run selenium tests with it. I'm willing to entertain it for a while and see how it goes, but my recommendation currently is to consider this spike conclusive: jest is not a good fit for traditional selenium-based testing. I think it would work better for unit tests, since jest is designed to be slow, but smart and only run tests against things that have changed. |
], | ||
"exclude": [ | ||
"node_modules" | ||
"common/*.ts", |
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.
should this be common/**/*.ts
to match files in common/util/
?
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's just a single file in there right now. util.ts
.
Ok I can make things much better for now by just cutting out firefox. Firefox + jest == not a good time. Chrome is alright. I'll get to the root of the issue as I spend more time on it, but I have to move on for now. |
Alright so I've made a lot of progress here. Firefox is slow because it takes up to 30 seconds to receive the "terminate" signal at the end of testing. The other slowness of the tests appears in both Chrome and Firefox, using the following set up. Reproduction steps include:
For some reason, Could it have something to do with image comparison speeding up a later operation via some kind of caching? Could it be a memory issue with jest's optimization strategies? There's a lot going on here but fortunately I have a couple of solid work arounds that will allow us to at least move on.
|
I've also discovered that it's only the first full size screenshot that does this. Subsequent full size screenshots don't take 10x less than the first one! |
|
||
> Snapshot 1 | ||
|
||
`<hx-reveal>␊ |
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.
Can we configure the newline characters in AVA?
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.
nm, I just realized that's on purpose to visualize new lines in the documentation
Feature request: dig through html source on disk during a before-all phase and find any |
test/package.json
Outdated
@@ -18,16 +18,20 @@ | |||
"scripts": { | |||
"build": "tsc", | |||
"clean": "npm run clean:visreg && npm run clean:func", | |||
"clean:func": "find functional/built -mindepth 1 \\( ! -path 'functional/built/functional/__snapshots__/*' \\) -delete ", | |||
"clean:visreg": "rm -rf visreg/screenshots visreg/built", | |||
"clean:func": "find built/functional -mindepth 1 \\( ! -path 'built/functional/*.js.snap' ! -path 'built/functional/*.js.md' \\) -delete", |
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.
If this gets any longer, move it into scripts/
.
test/package.json
Outdated
"postinstall": "[ -f bin/visreg.config.ts ] || cp bin/visreg{.example,}.config.ts", | ||
"previsreg": "npm run clean:visreg", | ||
"visreg": "npm run build && node built/bin/util.js && node built/bin/visreg.js", | ||
"webdriver": "npm run webdriver:update && npm run webdriver:start", | ||
"webdriver:start": "scripts/webdriver-start", | ||
"webdriver:update": "scripts/webdriver-update" | ||
}, | ||
"ava": { | ||
"snapshotLocation": "~/code/js/helix-ui/test/snapshots", |
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.
whoops.
I left this in as a failed attempt to get snapshotLocations
honored.
This is not a working feature.... 👎
test/visreg/visreg.ts
Outdated
await snap("{browserName}/nav/guides", $(util.selectors.nav)); | ||
}); | ||
|
||
test(`components`, async () => { |
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.
Drop the template literals.
Dev LGTM |
JIRA: https://jira.rax.io/browse/SURF-667
I'm pretty happy with this. I can do more polish here, but personally I'd rather just the core of this reviewed for now and address it during review.
Since jest is a pretty nice test runner, I decided to port over the visreg tests to it. This drops mocha and chai since otherwise we'd have two testing libraries used in the same project, which is not ideal.
These are kind of like unit tests, but they have a few differences that might be new to the team.
source/
directory, as jest doesn't like colocated testsBecause of the above three, I'd like to propose branding these as functional tests. Unit testing can be sorted out later once components of more substance are crafted. Currently, my working mental model of "unit" testing will include extracting out pure (read: node-friendly) classes and logic into their own modules and interleaving them into the source code with some kind of a build tool (likely webpack).
That would make it very pleasant to test. Require the module under test, instantiate the class containing business logic, and finally, pass in arguments to pure functions. Once you've verified that the outputs match what is expected, you're done. Afterwards, you can use that foundational business logic class in the html, extend it with
HTMLElement
like we do today, and let it do it's thing.From there, functional tests will ensure that interacting with it in the browser works as expected, with visreg as a final stop gap for measuring style changes over time.
LGTM's