39e0e0dda1
* Install liquidjs, uninstall liquid * Comment a bunch of stuff out to get going * Fix invalid includes * Fix all includes (path => 'path') * Get the homepage to render * Do link-in-list kinda * Revert "Fix all includes (path => 'path')" This reverts commit d6fead646353aa5041d9229470a62a1d487456b9. * Support non-dynamic partials * Extract getTemplate helper * Do remaining custom Liquid tags * Fix some custom tag bugs * Moar bugs * Re-add link tag * Cleaner diff * Actually fix extended markdown tags * Fully comment out version matchers * Smaller diff * Rely only on Liquid internals for conditionals * Use new operators option in Liquid engine * Fix link.js * Don't need options * Updoot to the right doot * Fix some bugs * Fix another bug * Pass a test * Fix the translate bits * Adjust a test * Fix another invalid Liquid bug * Two more borked translations * Found some more * Don't need this change * Revert "Don't need this change" This reverts commit a916d619747f0492865a69c3e237c97c4d4e7fad. * This should fix the broken links * Missed one * Revert "This should fix the broken links" This reverts commit e6c2cc0d9055d958706260d57edbe293281c150e. * Revert "Missed one" This reverts commit bbe1f23baf16e020f6f7931589decb1afc75dfbd. * Updoot liquidjs
Tests
It's not strictly necessary to run tests locally while developing: You can always open a pull request and rely on the CI service to run tests for you, but sometimes it's helpful to run tests locally before pushing your changes to GitHub.
Test are written using jest, a framework maintained by Facebook and used by many teams at GitHub. Jest is convenient in that it provides everything: a test runner, an assertion library, code coverage analysis, custom reporters for different types of test output, etc.
Running all the tests
Once you've followed the development instructions above, you can run the entire test suite locally:
script/test # or `npm test`
Watching all the tests
You can also run a script that will continually watch for changes and re-run the tests any time a change is made. This command will notify you when tests change to and from a passing or failing state, and will also print out a test coverage report, so you can see what files are in need of tests.
npm run test-watch
Testing individual files
If you're making changes to a specific file and don't want to run the entire
test suite, you can pass an argument to the jest testing tool:
jest __tests__/page.js
The argument doesn't have to be a fully qualified file path. It can also be a portion of a filename:
jest page # runs tests on __tests__/page.js and __tests__/pages.js
Linting
To validate all your JavaScript code (and auto-format some easily reparable mistakes), run the linter:
npm run lint
Broken link test
This test checks all internal links and image references in the English site. To run it locally (takes about 60 seconds):
npx jest links-and-images
It checks images, anchors, and links for every version of every page.
It reports five types of problems:
- Broken image references
- Example:
/assets/images/foo.pngwherefoo.pngdoesn't exist.
- Example:
- Broken same-page anchors
- Example:
#foowhere the page does not have a headingFoo.
- Example:
- Broken links due to page not found
- Example:
/github/using-git/foowhere there is nofoo.mdfile at that path.
- Example:
- Broken links due to versioning
- Example: an unversioned link to a Dotcom-only article in a page that has Enterprise versions.
- Broken anchors on links
- Example:
/some/valid/link#barwhere the linked page can be found but it does not have a headingBar.
- Example:
If you need to check S3 image references, you can run script/check-s3-images.js. See script/README for details.