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

Jest spike #66

Closed
wants to merge 23 commits into from
Closed

Jest spike #66

wants to merge 23 commits into from

Conversation

Droogans
Copy link
Contributor

@Droogans Droogans commented Oct 30, 2017

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.

  1. They use chrome, not karma (and, soon...chrome headless)
  2. They use selenium, but it could technically use jsdom, though there'd be a lot more boilerplate
  3. They don't live inside the source/ directory, as jest doesn't like colocated tests

Because 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

  • Dev LGTM
  • Zoom LGTM

test/index.ts Outdated
});
});
export function visregSuite(browserName: string) {
jasmine.DEFAULT_TIMEOUT_INTERVAL = 60e3;
Copy link
Contributor

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";
Copy link
Contributor

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.

@@ -20,15 +18,24 @@
},
"scripts": {
"build": "tsc",
"build:visreg": "tsc bin/visreg.ts bin/visreg.config.ts --outdir built/bin --lib es6 && tsc",
Copy link
Contributor

Choose a reason for hiding this comment

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

Clean this up

"webdriver": "npm run webdriver:update && npm run webdriver:start",
"webdriver:update": "scripts/webdriver-update",
"webdriver:start": "scripts/webdriver-start"
},
"jest": {
Copy link
Contributor

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"
Copy link
Contributor

Choose a reason for hiding this comment

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

Document this better.

@CITguy
Copy link
Contributor

CITguy commented Oct 31, 2017

Future request: plug in tests into bin/start.js so that tests run automatically when devs run yarn start

Copy link
Contributor

@cathysiller cathysiller left a comment

Choose a reason for hiding this comment

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

Dev LGTM

@Droogans
Copy link
Contributor Author

@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.

@Droogans
Copy link
Contributor Author

Droogans commented Nov 1, 2017

@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",
Copy link
Contributor

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/?

Copy link
Contributor Author

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.

@Droogans
Copy link
Contributor Author

Droogans commented Nov 1, 2017

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.

@Droogans
Copy link
Contributor Author

Droogans commented Nov 2, 2017

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:

  1. Use jest (this doesn't happen with mocha)
  2. Delete your screenshots directory (when a previous screenshot exists, this doesn't happen)
  3. Take a full page screenshot

For some reason, pngjs.PNG.sync.write(this.png); can take up to two minutes to run when there is no baseline. I'm working on profiling the calls and digging into our source modules to find out what could possibly be causing this, since it appears to only happen in the context of jest.

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.

  1. Use Chrome
  2. Don't take full-page screen shots.

@Droogans
Copy link
Contributor Author

Droogans commented Nov 2, 2017

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>␊
Copy link
Contributor

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?

Copy link
Contributor

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

@Droogans
Copy link
Contributor Author

Droogans commented Nov 2, 2017

Feature request: dig through html source on disk during a before-all phase and find any data-visreg attrs on tags to generate visreg test cases.

@@ -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",
Copy link
Contributor Author

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/.

"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",
Copy link
Contributor Author

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.... 👎

await snap("{browserName}/nav/guides", $(util.selectors.nav));
});

test(`components`, async () => {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Drop the template literals.

@CITguy
Copy link
Contributor

CITguy commented Nov 2, 2017

Dev LGTM

@Droogans
Copy link
Contributor Author

Droogans commented Nov 2, 2017

@Droogans Droogans mentioned this pull request Nov 2, 2017
3 tasks
@Droogans Droogans closed this Nov 2, 2017
@CITguy CITguy deleted the jest-spike branch March 7, 2018 00:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants