-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split tests into core/tasks #391
Comments
For the record, this is the command that runs even without package extras:
|
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). |
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. |
#425 implements a first version of this split in tests What is covered is:
Out of scope, for now:
|
Split tests folder into core/tasks (ref #391)
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:
The text was updated successfully, but these errors were encountered: