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
sinon.restore() && sandbox.restore() not restoring fakes #2065
Comments
As it is, it looks like a bug, but to be honest, I am not totally sure about this. I remember a key point on fakes is that they were supposed to be immutable in some sense, but since they do have state (i.e. they know if they have been called), that immutability must be restricted to only the stubbing behavior, I assume. @mroderick might be the right person to answer this ... If this is the right behavior, we should at least update the docs. |
Was just bit by this bug myself, so this would be nice to get fixed. |
If no one else makes a PR for it in the next few days, I can see if I can find the time to fix it |
I looked into this now and the docs are a bit misleading, as is the test above. It actually seems to do (almost) what it says, but let's just define some terms first: restore - restoring a sandbox means restoring all stubbed functions to their original state, meaning the stubs are removed from each object were they overwrote the original. The problem with the above test is that it
That doesn't make sense :-) I have tested and both the |
Closing this as not reproducible, but opening a new issue on the To verify: https://runkit.com/fatso83/sinon-issue-2065 |
I can confirm that this bug is also happening to me, I have a test scenario that requires the implementation to be intact, but the function carries the stub result from a previous test, which means that This is happening to me on version |
@oscarr-reyes Can you check if 54df7f7 fixes it for you? I think it didn't make it into a new release yet. |
@oscarr-reyes Are you able to make a reproducible example? We have not yet actually seen this bug. If you look at the thread above, and my explanation, you'll see the only bug we found was a single flag hadn't been cleared. Everything else works. So unless we actually see some proof, there is no bug (apart from the lastArg flag). |
I have facing the same issue. I am sandboxing my "validateCaptcha" middleware and when I restore it continues issuing the stub. /src/middlewares/captcha.js
/test/api/user.spec.js
What I'm doing to check that it doesn't work is:
Inside beforeAll there is a comment "sandbox.restore();" that I have tried and there it worked... but it is useless I am also doing require each time to my app.js |
Five minutes ago I have modified it to:
|
I am seeing this issue as well. Why is this closed? |
It may be that the behaviour of restore is sensitive to the specific syntax used to set up the stub. Afaik both of these should be valid ways of doing this but the restore() is different. In one it works and in the other it has unexpected results. const sinon = require('sinon')
// restore does not work as expected
let db = {
query: () => {
return 'my query 1'
}
}
const dbStub = sinon.stub().resolves('somejson')
db.query = dbStub
db.query() // somejson
sinon.restore()
db.query() // resolves nothing
// restore works as expected
db = {
query: () => {
return 'my query 1'
}
}
sinon.stub(db, 'query').resolves('somejson')
db.query() // somejson
sinon.restore()
db.query() //my query 1 |
@scottpatrickwright when you do assignments directly to |
@scottpatrickwright It's closed because there is no bug, as should be apparent from the thread. It was just user error, as in your case: it works as described and intended :-) The Sinon sandbox can clean up things it knows about. That means Sinon has to have knowledge of the objects with which it interacts. The stub you describe above is made standalone. Sinon is not made aware of any of the objects you assign it to. That changes in the second example. You could also do |
Fair enough - thanks for the explanation.
…On Fri, Feb 19, 2021 at 7:02 AM Carl-Erik Kopseng ***@***.***> wrote:
@scottpatrickwright <https://github.com/scottpatrickwright> It's closed
because there is no bug, as should be apparent from the thread. It was just
user error, as in your case: it works as described and intended :-)
The Sinon sandbox can clean up things it knows about. That means Sinon has
to have knowledge of the objects with which it interacts. The stub you
describe above is made standalone. Sinon is not made aware of any of the
objects you assign it to. That changes in the second example. You could
also do sinon.replace(obj, fieldname, fake) to achieve the same. It's just
JavaScript 🙂
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2065 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKKRTFVMGEYVIB5GSIDXKTS7ZHMRANCNFSM4IGBASQQ>
.
|
ok I have just run into this with Test code:
Driver code:
Expected: Actual: The example code is consistent with the guidance given in https://sinonjs.org/releases/latest/stubs/ and it does not work? Does sinon not know how to reset nested stubs? |
@neondizen Sinon does restore correctly, but it is not immune to usage errors 😃 As detailed in my response in your other issue #2376 (comment) the problem you experience is caused by
To make your tests "immutable" you would need to change the client code to create new secret managers for each invocation or make your tests reset the module somehow. I linked some ways of doing this in my reply. |
People that have read the thread and understood why it was closed and locked (because we have not seen a bug after inspecting several reports) and still mean they have an actual reproducible bug with code to back it up can visit #2473 (which is yet to be verified). |
Describe the bug
Can't clear fakes
sinon.restore()
(norresetHistory
,resetBehavior
, norreset
). I then tried creating a new sandbox, and clearing the sandbox. No dice. Is this intentional?To Reproduce
Expected behavior
I expected
thing.lastArg
to be eitherundefined
ornull
. It gives me"Hi"
Screenshots
N/a
Context (please complete the following information):
Additional context
Just testing the capabilities of Sinon as I use it to test a backend.
The text was updated successfully, but these errors were encountered: