Refactor division by zero error test in test_tth_to_d
#260
Conversation
|
|
||
| @pytest.mark.parametrize( | ||
| "q, expected_d", | ||
| "q, expected_d, warning_expected", |
There was a problem hiding this comment.
I am thinking having warning_expected explicitly provides a quick overview whether each test case provides a warning or not. @sbillinge how do you like it?
|
@sbillinge ready for review - again bite size PR |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #260 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 8 8
Lines 380 387 +7
=========================================
+ Hits 380 387 +7
|
news/pytest-handle-warning.rst
Outdated
| @@ -0,0 +1,23 @@ | |||
| **Added:** | |||
|
|
|||
| * No news added | |||
There was a problem hiding this comment.
I think this woul benefit from a news.
| # UC1: User specified empty q values | ||
| (np.array([]), np.array([])), | ||
| # UC2: User specified valid q values | ||
| # Case 1: empty q values, expect empty d values |
There was a problem hiding this comment.
Let's put a high level contextual statement always to make it easier to review. To see what I mean you could look at my edits to the PR on scale_to and eq.
Here it would be something like
# test conversion of q to d with good values
# Case 1: empty q values, expect empty d values
...
# Case 2: valid q values, expect d values without warning
...
Case 3. valid q values containing 0, expect d values with divide by zero warning
@sbillinge ready for review - added higher-level test comment and also news file. There are still two dozen warnings. I will address them in separate PRs. |
2 participants
No description provided.