Organise unit tests to use pytest fixtures #172
Conversation
Codecov Report
@@ Coverage Diff @@
## main #172 +/- ##
==========================================
- Coverage 88.58% 87.10% -1.48%
==========================================
Files 26 25 -1
Lines 1603 1613 +10
==========================================
- Hits 1420 1405 -15
- Misses 183 208 +25
|
|
I have reorganised a few tests files just to see what it looks like. @ccarouge @bschroeter it would be great if I can get your thoughts before I push on further. |
tests/test_comparison.py
Outdated
| ) | ||
| @pytest.fixture | ||
| def bitwise_cmp_dir(self, mock_cwd): | ||
| _bitwise_cmp_dir = mock_cwd / internal.FLUXSITE_BITWISE_CMP_DIR |
There was a problem hiding this comment.
With the mock_cwd fixture, it means you can use a relative path here (internal.FLUXSITE_BITWISE_CMP_DIR only). It might lighten up the tests. Might be applicable elsewhere.
tests/test_comparison.py
Outdated
| comparison_task.run() | ||
| assert f"nccmp -df {file_a} {file_b}" in mock_subprocess_handler.commands | ||
|
|
||
| def test_default_standard_output(self, comparison_task, files): |
There was a problem hiding this comment.
I wonder if we could instead use the test parameterization to write one output test that runs on all output cases. But this might wait for after the reorganisation?
There was a problem hiding this comment.
It should be possible to use parameterisation for testing different verbosity levels. I'll look into it
I think I prefer we do the merge into main as a single PR. But we can treat this branch as 'main' for this issue and create other branches that implement small changes and have those merged into this branch? |
Yes, that would be better! |
|
|
||
|
|
||
| @pytest.fixture | ||
| def config(): |
There was a problem hiding this comment.
So I am going to approve this section, but bearing in mind that some of the changes I've made to the configuration validation system (which now has the bonus feature of installing a data directory [which contains tests]) have simplified this process significantly.
I'll have a fun merge on my hands after this one...
SeanBryan51
force-pushed
the
163-tidy-up-organisation-of-unit-tests
branch
from
30f4ce3
to
19eff9e
Compare
|
@ccarouge I've rebased this branch off main so that we have the recently merged changes (e.g. linting with ruff). I've added the changes you requested for using pytest's |
|
@SeanBryan51 It seems you asked my review again on this meta-PR. Is that correct? |
SeanBryan51
force-pushed
the
163-tidy-up-organisation-of-unit-tests
branch
from
c03e814
to
eaa440b
Compare
Unit tests have an excessive amount of repeated test setup code, making unit tests harder to maintain and read. Using pytest fixtures to setup each test would remove needless code repetition and also prevents the possibility of state leaking into each test case. Organise the tests so that for each function `func`, we have a test class `TestFunc` with each method of `TestFunc` containing a single test (success or failure case). Use pytest's `parametrize()` feature for testing different levels of verbosity. Remove usage of `mock_cwd` fixture unless it is required for a test to pass. Fixes #163
SeanBryan51
force-pushed
the
163-tidy-up-organisation-of-unit-tests
branch
from
9d88427
to
107cc86
Compare
Unit tests have an excessive amount of repeated test setup code, making unit tests harder to maintain and read. Using pytest fixtures to setup each test would remove needless code repetition and also prevents the possibility of state leaking into each test case.
Organise the tests so that for each function
func, we have a test classTestFuncwith each method ofTestFunccontaining a single test (success or failure case).Use pytest's
parametrize()feature for testing different levels of verbosity.Remove usage of
mock_cwdfixture unless it is required for a test to pass.Fixes #163