-
Notifications
You must be signed in to change notification settings - Fork 142
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
Arguments of mocked functions are saved by reference. #375
Comments
Thanks for raising this issue. I guess it's a testament to our users that for ~3 years nobody has actually encountered and reported an issue having to do with mutating values passed to the library. There are a few things to unwind here:
Taken in isolation, I don't have great answers to any of these three questions. My only stance initially on this is to approach the idea of changing this behavior with trepidation, given that we've gone several years and hundreds of projects without this ever raising an actual issue. Would love other opinions on this. |
@searls thanks for taking the time to reply to this issue. I will try to answer your first 2 questions, Ignoring performance and implementation difficulty and focus on usability only:
However, if To avoid the performance hit and the possible implementation pitfalls, I think it is ok to keep just a copy of the matching properties ( It will not solve my example above, but I believe it will solve 99% of the use cases. |
I've never seen or heard of the problem your (more narrow) proposed solution would fix, so I'm not especially inclined to try to fix it until we see data that this is a real pain point for people. For stubbing, "matching to be based on the properties of the object at the moment of the invocation" is already how it works, since arguments and matchers passed to Moreover, I'm struggling to think of cases when this could happen where the subject code wouldn't be exhibiting the code smell of operating at multiple levels of abstraction (if we've faked our dependencies and make sure I'm going to close until we observe more examples of problem cases, so we can find real-world pain that isn't exhibiting some other design smell. I'd like to take that step before covering additional edge cases in the library's behavior. Please don't read this as my being dismissive, I'm just trying to be really cautious and thoughtful about changes to the library's more well-established behavior. |
If the pain point here is in |
This means that if an arg is mutated, users will see the real one for recorded invocation. Fixes #375
Landed in 3.12.0 via #417 |
Description
Arguments of mocked functions are saved by reference.
I expect
explain
to show calls tof
withsome="1"
andsome="2"
. However, it shows it withsome="2"
twice.Issue
The code example below printed the following:
name: Salvador last: Sobral <-- first call
name: Netta last: Barzilai
Call 1. name: Netta last: Barzilai <-- first call according to expect
Call 2. name: Netta last: Barzilai
Environment
node -v
output: v8.11.2npm -v
(oryarn --version
) output: 5.6.0npm ls testdouble
(oryarn list testdouble
) version: testdouble@3.8.1Code-fenced Examples
The text was updated successfully, but these errors were encountered: