tapret_wlt_receiving_opret 100 times #16
Conversation
| @@ -776,4 +779,30 @@ fn tapret_wlt_receiving_opret() { | |||
| 1000, | |||
| None, | |||
| ); | |||
| assert_eq!(consignment.bundles.len(), 0); | |||
There was a problem hiding this comment.
But this must be 3, isn't it?
There was a problem hiding this comment.
Yes, 0 is incorrect. The "fixing" PR has introduced this bug, as explained in #6 (comment)
There was a problem hiding this comment.
If this is a bug I believe it must be a failing assertion, so we do not merge this PR unless the bug is fixed
There was a problem hiding this comment.
Please check the message of this PR, it says:
This is not meant to be merged, it's just here to push ahead the discussion in #6
There was a problem hiding this comment.
Yes, I see that, but what confuses me is that all other PRs here fail unless there is a fix - and this one follows different approach
There was a problem hiding this comment.
The purpose of this PR is showing the tests are deterministic and there is no such case of consignment changing the number of bundles based on a run executed on a different hour/day. If I change the assertion the test would fail and it wouldn't be possible to show that it deterministically returns 0 bundles at every run. I don't see any issue in having a PR with a different approach since there are no better alternatives. Do you see alternatives?
This PR adds on top of #6:
fix/271(of PR Always add opret anchors when preset to a consignment rgb-std#272)tapret_wlt_receiving_oprettest 100 timesThis is not meant to be merged, it's just here to push ahead the discussion in #6