Use Cypress so tests run & pass in a real browser #16
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
agilgur5
commented
Nov 27, 2019
There was a problem hiding this comment.
This took a TON of time to figure out how to get the browserify config to work and not take suuuper long and then a bit more to figure out how to create a "custom" preprocessor to call either webpack or browserify. It looks ALMOST good to go now, finally.
Have one TODO left in the first commit, which is to potentially optimize Cypress's config more. Also might want to move it from cypress.json into cypress/support/index.js so that it's with the screenshot config (should also probably suggest/PR that this be available directly in CI though).
There's also a typo in the first commit message: "rfactor"
agilgur5
force-pushed
the
cypress-test
branch
from
d414911 to
999562d
Compare
- use a full browser for testing instead of running in Node and
relying on JSDOM, which does not implement all of the features we
use (namely worker-related stuff)
- this ensures tests run without any errors
- use cypress's webpack and browserify preprocessors to bundle up the
code and tests for each instead of building the bundles outside of
the test process
- at least one of these is needed (browserify is cypress's default)
because we use `require` in tests, which isn't available in a
browser ofc
- and actually using the browserify preprocessor on the browserify
bundle caused lots of errors (it seems to use its own `require`
when parsing the bundle, causing module not found errors)
- no need for several package.json scripts anymore
- no need for webpack-cli anymore
- no need for helper files for import / export anymore
- move the webpack and browserify config into the cypress preprocessor
config
- cypress handles input and output, so those sections can be entirely
removed, basically just leaving noParse
- can't use externals here because those have to be provided to the
browser (otherwise will give a ReferenceError)
- move the tests to cypress/integration/, cypress's default folder
- and refactor them to cypress's mocha/chai style from AVA style
- basically everything was (re)moved from test/ to cypress/
- Node 8 Maintenance LTS is EOL in Jan 2020 - this also updates NPM to v6.9.0 (from v5.6.0) - could add some CI perf, esp w/ new usage of `npm ci` - but we run in under a minute anyway, so hard to beat that! - Cypress also seems to need Node 10 to run on Travis CI - https://docs.cypress.io/guides/guides/continuous-integration.html#Travis - https://travis-ci.org/agilgur5/physijs-webpack/builds/617388969
- per Cypress Travis CI directions - https://docs.cypress.io/guides/guides/continuous-integration.html#Travis - the other stuff isn't necessary for our specific setup or are currently Travis CI defaults - like install: npm ci and cache: npm: true are defaults
agilgur5
force-pushed
the
cypress-test
branch
from
999562d to
3851267
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Alternative to #15 that uses Cypress instead. Similarly fixes #7 and fixes #14
Jest w/ Electron runs faster, and I prefer Jest's test runner and output quite a bit more than Cypress, so I'm likely going to merge that one instead. It also doesn't have any Cypress-specific gimmicks like the directories, plugins, config etc, so it requires less context to use and is probably more familiar to more people (though the Cypress-specific stuff does cut down on all the scripts and helpers fwiw).
Buuuut Cypress allows (requires actually) you to custom instrument your code for code coverage. Jest does it for you, which is great for most use cases, but it seems to give no flexibility and so it runs into the infinite cycle errors. I'll go over that more on #6, but for now we could stick with Jest w/ Electron and maybe eventually move to Cypress... that is if coverage actually ever works correctly 😕