-
Notifications
You must be signed in to change notification settings - Fork 46
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
editoast: improve tests for projection #10137
Conversation
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## dev #10137 +/- ##
==========================================
- Coverage 79.84% 79.81% -0.03%
==========================================
Files 1054 1054
Lines 105571 105530 -41
Branches 726 726
==========================================
- Hits 84292 84231 -61
- Misses 21237 21257 +20
Partials 42 42
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ 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.
Thank you for the PR. I’ve left two comments.
All the existing test follow the same pattern. Since we do have `rstest` that allows us to express them as cases of the same test, let's use that. In order to shorten (and, subjectively, make it more readable and concise?), I also implemented a `FromStr` for `TrackRange`. It's a nice helper to express all the tests more concisely. Signed-off-by: Jean SIMARD <[email protected]>
It's easy to add tests, let's add some more for this tricky algorithm. Signed-off-by: Jean SIMARD <[email protected]>
The idea is to tests all projection, and combine all possible directions. So if we have a test on a projection of B (with direction `StartToStop`) on A (with direction `StartToStop`), we can automate also all combinations of directions for A and for B: - when B is reversed, no change in the expected results (direction of the projected track range has no impact) - when A is reversed, we need to calculate all the offset from the end and therefore, all intersections are inverted. Signed-off-by: Jean SIMARD <[email protected]>
3750ea8
to
72eb803
Compare
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.
LGTM. Much better!
We're planning a rework of the projection algorithm to support a case that is not supported today: project multiple times the same track range (possibly different offset). This use case is brought to us by work schedule which might have this pattern.
In order to have a good refactoring without breaking anything, let's have even more tests.
Note
Review by commit
rstest
cases to express tests in a more concise wayWarning
The third commit significantly make the test code harder to read so I'd be happy to discuss it...