Split tests into core/tasks

[tcompa]

After #378, we should also run the tests in two batches: the ones for the core functions, and the ones for the whole package that also include tasks. This will protect us from issues like "I added a cellpose dependency in the core library". Not the most urgent thing to do, but it's always good to improve the tooling of the repo/package.

Note that pytest does offer some kind of test labels (which we would also use to run the CI locally), but we'll still need to properly set up the GitHub action so that:

1. It installs the core part
2. It runs the core tests
3. It install the tasks extra
4. It runs the tasks tests
5. It creates a unique coverage report

[tcompa]

For the record, this is the command that runs even without package extras:

poetry run pytest -x -v --ignore tests/test_unit_napari_workflows_wrapper.py --ignore tests/test_unit_parse_yokogawa_metadata.py --ignore tests/test_workflows_napari_workflows   --ignore tests/test_workflows_cellpose_segmentation.py --ignore tests/test_workflows_napari_workflows.py --ignore tests/test_import.py --ignore tests/test_valid_args_schemas.py --ignore tests/test_valid_task_interface.py

[tcompa]

Side comment: splitting the tests into core+tasks will also make it clear that some of our core modules require a much more thorough test coverage, e.g. I just realized that lib_masked_loading.py has a very poor one.

For a task, it could be complex to create and maintain test data for all branches, but for the core modules I think we should aim for a very high quality (this is especially true because we plan to have other packages depending on the core part).

[jluethi]

Agreed!

I also just realized how complex this can become for the napari workflows task when looking at the different 2D & 3D branches, those are hard to test exhaustively. But we should aim for high test coverage over our library functions.

[tcompa]

425 implements a first version of this split in tests

What is covered is:

• Fail fast if one of the core (i.e. not related to tasks) tests fail, for instance because we use a dependency that is listed in the fractal-tasks extra
• Run the core-library and tasks tests in parallel (this is not very relevant at the moment, since the tasks tests take much longer.. but it could become relevant if we either trim down the tasks tests or make the core-library tests much more time-consuming)
• Run the core-library tests also for python 3.11 (ref #392)
• Keep providing a comprehensive coverage report, for both the main package and the tasks subpackage

Out of scope, for now:

• Providing a more granular coverage report, that also shows the coverage for the core library alone (note that this is already visible in https://htmlpreview.github.io/?https://github.com/fractal-analytics-platform/fractal-tasks-core/blob/python-coverage-comment-action-data/htmlcov/index.html, even if not aggregated)