-
Notifications
You must be signed in to change notification settings - Fork 2
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
Refactor tests #27
Refactor tests #27
Conversation
23a485d
to
a9f8f11
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #27 +/- ##
==========================================
+ Coverage 80.85% 81.31% +0.45%
==========================================
Files 28 32 +4
Lines 1494 1584 +90
==========================================
+ Hits 1208 1288 +80
- Misses 286 296 +10 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking really good - a lot of my comments are just suggestions/requests for clarifying docstrings. Some thoughts to your questions below:
- I wanted to define fixtures per test module and used multiple conftest.py files to do so. But I'm not sure if that makes any difference compared to the case of having all of the fixtures in one conftest.py file (I think pytest just looks for conftest.py files and loads them all at once). Is there a better way to define fixtures per test module?
Even if pytest loads them all at once, having the conftest.py
per subfolder still expresses the developer's intent as to where they should be used? In addition, I'd say keep fixtures that are used in just one file in that file (until they are needed in several files of the same module)?
- For a few commits I replaced the use of
arparse
by typer, and the code look cleaner and more readable, but at the cost of adding an extra dependency. Chatting to Adam he mentioned in brainglobe we try to keep dependencies lists short, so I reverted back toargparse
but let me know if you have any thoughts about it.
I'd agree with Adam that minimising the number of dependencies is worth it here. As an additional benefit, I'd say that argparse
is the de facto default for this (as part of the Python standard library) so future contributors are less likely to need to look up what typer
is.
tests/test_integration/brainglobe_benchmarks/test_cellfinder.py
Outdated
Show resolved
Hide resolved
These two questions relate to our live discussion of where the workflow data should live, and to a further thought of mine that feels that a lot of the test code is still a bit complicated.
I think the parametrisations you've done are fine, but I'd say the
Yes, I think caching is worth it long-term to improve the development experience. If we move to using paths relative to The test code would then be something like: def test_main(
):
"""Test main function for setting up and running cellfinder workflow (default case)
"""
# mocking of $HOME in conftest.py takes care that test data and user data are separate
cfg = main()
# check output files exist
assert (cfg.detected_cells_path).is_file()
@pytest.mark.parametrize(
"input_config",
[
"input_config_fetch_GIN",
"input_config_fetch_local",
],
)
def test_main_non_default(
):
"""Test main function for setting up and running cellfinder workflow
Parameters
----------
input_config : Optional[str]
Path to input config json file
"""
# mocking of $HOME in conftest.py takes care that test data and user data are separate
cfg = main(str(Path.home()/".brainglobe/cellfinder/workflows"/input_config))
# check output files exist
assert (cfg.detected_cells_path).is_file() This can also be part of a separate PR |
Co-authored-by: Alessandro Felder <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is ready to be merged - thanks a lot @sfmig ! - and will allow us to run our first benchmarks 🎉
As we move iteratively forwards and refactor, we should keep in mind the main user-facing purpose of this repo, which is to easily re-use and adapt the workflows.
A PR for refactoring the cellfinder workflow tests, following the feedback collected on issue #26.
Main features
They address the points from issue #26:
utils.py
moduleconftest.py
for the fixtures that are shared between unit and integration tests. I also use an additionalconftest.py
for the fixtures shared between utils unit tests and cellfinder-specific unit tests.make_config
helper functions by config files that are part of the test dataOther additions
brainglobe_workflows/configs
)benchmarks
directory tobrainglobe_benchmarks
cellfinder
subdirectory underbrainglobe_workflows
cellfinder-workflow
Comments / questions
arparse
by typer, and the code look cleaner and more readable, but at the cost of adding an extra dependency. Chatting to Adam he mentioned in brainglobe we try to keep dependencies lists short, so I reverted back toargparse
but let me know if you have any thoughts about it.