Reduce GitHub Actions unit test durations by removing tox and using test parallelization

[jayaddison]

I removed unittest-parallel from our test suite a couple of years ago in #660, under the justification that it introduced unnecessarily complexity.

However: to support a potential increase in the number of pull requests we run tests for, and based on noticing an increase in the number of continuous integration machine-minutes spent, I'd like to see if we can reduce the duration of our GitHub Actions unit test workflows, and believe that unittest-parallel may be an effective way to do that. So here it is again, although only as a dependency during the relevant workflow.

Depends-upon / includes:

• Tests: refactor: simplify assignment of util test fixtures #1342
• Tests: correctness: ensure that deprecation warnings are always emitted when checking for them #1343
• Tests: prepare test cases at module import-time #1344
• ci: refactor: remove GitHub Actions unit test workflow dependency on 'tox' #1339

[jayaddison]

Note: removal of tox also contributes to the reduction in test runtime here; I introduced it in #650 -- feeling that it provided useful standardisation and isolation of tests.

[jknndy]

This seems like a great improvement, running the parallel tests on my local machine cut runtime by over 35 seconds. I wonder if it would be worth including information about this alternative testing method in the readme if it gets merged.

[jayaddison]

I'm not sure how to decide about that, to be honest. It's good that the library should (and does, afaik) be testable with a super-simple, standard workflow (create a venv, source that, pip install, run unittest) -- but also it's certainly nice to save people time and maybe some compute resource (although running stuff in parallel, arguably doesn't always save CPU/memory.. sometimes it only compresses it, and could even add a tiny amount of overhead).

[jknndy]

It's good that the library should (and does, afaik) be testable with a super-simple, standard workflow

We could include something in the existing docs/how-to-develop-scraper.md below the current documentation regarding testing.

**Check that everything is working by running the tests**
~```shell
$ python -m unittest
~```
This will run all the tests for all the scrapers. You should not see any errors or failures

**OPTIONAL: To run the full test suite in parallel**
~```shell
$ pip install unittest-parallel
$ unittest-parallel --level test
~```

[jknndy]

Great improvements all around!

Once #1343 is merged this will be a great addition.

[jayaddison]

Thanks again - and agreed with the idea of adding the parallel-tests mode to the dev documentation. Merging this soon.

[jayaddison]

(ah, ok; some refactoring of the documentation required first, by the looks of it. I'll spend some time on that during the week)

[jayaddison]

(ah, ok; some refactoring of the documentation required first, by the looks of it. I'll spend some time on that during the week)

In fact... on second thoughts; let's merge the test-parallelism for continuous integration first, because that affects open pull requests and merges. I'll include the documentation change during the week.

[jayaddison]

Note: this change appears to have been incompatible with the v14 branch; that isn't something I had considered could be possible before backporting it there, but it is.

It seems that this legacy test is the problem there:

recipe-scrapers/tests/legacy/__init__.py

Line 50 in 11e7ed2

cls.harvester_class = cls.scraper_class(url=start_url)

I'll investigate that soon. In some ways it appears that it could be similar to #1342 (per-class test setup).