Testing tasks

[andreww]

The notebook testing pull request also enables tests on (new) pull requests. This should give a nice green tick that can be used to help to decide when to merge. It's probably worth enforcing this via the branch protection stuff on github (so changes to main only go via pull requests, and so all tests pass). Doesn't avoid the cheap hack of turning off a test we cannot fix, but at least we'll know we're doing it.

It's probably also good practice to have the test system enable linting (style checks). But before we do that we should fix any lint errors in the code first. And before that we should decide on the rules to enforce. Ultimately we'll need something like the following (which is a lax example) in the github workflow:

    - name: Lint with flake8
      run: |
        python3 -m pip install flake8
        # stop the build if there are Python syntax errors or undefined names
        flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
        # exit-zero treats all errors as warnings. The GitHub editor is 127 chars wide
        flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics

unless we want to go hard-core with black?

Documenting how to contribute somewhere is probably a good thing too (do we need a contributors code of conduct?)

We should probably add some test coverage reporting. And more tests. What else?

[andreww]

This is all done by #12 except for the documentation (developers should develop on branches, they need review, how to run tests locally, how to check test coverage, how to lint). Probably needs a page in the docs on 'contributing'.