Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix bugs with mock/spy result tracking of recursive functions. #6381
Results of mocks/spies were not being recorded properly for recursive functions because the result of the call was pushed onto an array AFTER the function returned (results were in reverse order).
I have reworked the result recording code to push an object onto the "results" array immediately upon calling the mock (with values representing an "incomplete" call), then update that same result object upon returning.
See new unit tests. Edge cases related to recursion are now covered (including testing mock result state and calling expect return matchers from inside of the recursive function).
The structure of the
referenced this pull request
Jun 2, 2018
@@ Coverage Diff @@ ## master #6381 +/- ## ========================================== + Coverage 63.57% 63.59% +0.01% ========================================== Files 235 235 Lines 8992 8996 +4 Branches 3 4 +1 ========================================== + Hits 5717 5721 +4 Misses 3274 3274 Partials 1 1
One of the CI tests failed during yarn install:
@UselessPickles yeah I'm ok with the change to mock_serializer as long as this goes in a minor version and not a patch, we've done snapshot updates for minor versions in the past
If you update the changelog, should it be something like
Do we just want to remove the "deprecated"
Oct 31, 2018
9 of 10 checks passed
added a commit
this pull request
Nov 2, 2018
Hey @UselessPickles, I just saw this PR after releasing 24.0.0-alpha.6. Would you mind updating the PR (mainly the title) to better reflect the implications of the changes you did here? In this case, the structure of mock objects have changed for end-users and that's not clear by reading this. E.g.:
I can edit the PR but I prefer if the original author can do it. I'll update the changelog soon so you don't have to worry about that.
I think the PR title accurately describes the purpose of this PR. The PR description clearly explains the breaking change. The entry in the change log clearly indicates that there is a breaking change. I see nothing wrong.
If the goal is to compile a list of breaking changes and a migration guide, then all the necessary information is already there.
I don't know what you would expect from the title to both describe the PR purpose and indicate breaking changes. Feel free to change it.
Perhaps I didn't use the better wording here. I think this should've been 2 different PRs: one to change the mock interface and another to fix their behaviour with recursive functions. The most relevant change here is the change in the interface, even though your initial goal with this PR was to fix the issue.
The breaking change came about during the PR review process (at the request of a reviewer). It was not originally a breaking change, and even the design of the breaking change changed over time (at one point retaining deprecated backward compatibility, etc.). I don't think it would have been practical to separate it into two PRs until the very end when the entire change was approved. Hindsight, etc.
Again... I really don't know what you expect from an updated title, so I'm the wrong person to make the change. You can update the title/description however you see fit to clarify the breaking change. I won't be offended :)