Back on my old 2013 Macbook Pro, 2 was the optimum number of cores for the fastest test runs. Which is why I chose `-n2` when I originally introduced this flag (see 9ced677ec7).
Now I have a faster Macbook (same as every other developer), which has more cores to take advantage of.
We also use 4 cores when running the API tests.
Cores | Time taken to run tests
--- | ---
1 | 28.31s
2 | 18.15s
3 | 14.33s
4 | 12.32s
5 | 12.98s
6 | 13.49s
8 | 15.37s
PEP8 was renamed to pycodestyle; this issue explains why:
PyCQA/pycodestyle#466
This commit changes our tests to use pycodestyle instead of pep8.
No changes to our code were required as a result.
We can make the tests run slightly faster by parallelizing them across
multiple CPU cores:
- from some casual testing locally, 2 cores gives the optimum speedup
- Travis container-based builds have 2 CPU cores available[1]
- the net gain is about 20%, or 2 seconds
- unfortunately we can’t do this on the API because each test is still
using the same instance of the database
1. https://docs.travis-ci.com/user/ci-environment/#Virtualization-environments
- no config overrides - now all set in environment
- use different files for staging and live too allow for differently named env variables
- updates to run_app and run_tests scripts to set correct environment (test/development) so correct config picked up
- use environment file on deployed environments to pick correct config
Similar to how PEP8 enforces Python style, there are tools for front end code:
- jshint[1] for Javascript
- sass-lint[2] for SASS
This commit adds the Gulp plugins for both, and sets up some sensible rules
(which can be iterated on).
It also adds a command to `./scripts/run_tests.sh`, so that any errors in the
front end code will fail the build before it has a chance to be deployed.
1. http://jshint.com/
2. https://www.npmjs.com/package/sass-lint
