Wishlist: Have fakeServer record requests #1237
Comments
|
It looks like this should already be happening. Will consider this a non-issue until you can supply us with some code that proves this is not the case, or that can clear up whatever misunderstanding I have created in my head 😃 |
|
I think you are correct. I was planning to close this issue but you beat me to it. It is still a documentation issue, isn't it? I tried to find out which file I should file a PR against, but failed to find out. If you can point me towards it I'll cook up a PR. Regards, |
|
Improvements are welcome. We are in the process of building a new site for the Sinon, so the online docs and the source docs might differ. Relevant file here. |
fatso83
added a commit
to fatso83/sinon
that referenced
this issue
Sep 12, 2017
This was a longer discussion that can be found in the issues sinonjs#1508, sinonjs#1552 and sinonjs#1537 - and internally amongst the core team. Support for stubbing props using get()/set() was added in sinonjs#1237 and also worked for undefined properties. This type of behavior (stubbing undefined props) has been explicitly disabled for sandboxes, so in order for Sinon to behave in a consistent way, we should do the same here. This change will bring normal stubs back to how it has used to be historically, and will make sandbox stubs and normal sinon stubs behave the same. It might break things for people relying on the behavior that has been present since Sinon 2.0, but it should make things more reliable going forward.
fatso83
added a commit
to fatso83/sinon
that referenced
this issue
Sep 13, 2017
This was a longer discussion that can be found in the issues sinonjs#1508, sinonjs#1552 and sinonjs#1537 - and internally amongst the core team. Support for stubbing props using get()/set() was added in sinonjs#1237 and also worked for undefined properties. This type of behavior (stubbing undefined props) has been explicitly disabled for sandboxes, so in order for Sinon to behave in a consistent way, we should do the same here. This change will bring normal stubs back to how it has used to be historically, and will make sandbox stubs and normal sinon stubs behave the same. It might break things for people relying on the behavior that has been present since Sinon 2.0, but it should make things more reliable going forward.
fatso83
added a commit
that referenced
this issue
Sep 18, 2017
This was a longer discussion that can be found in the issues #1508, #1552 and #1537 - and internally amongst the core team. Support for stubbing props using get()/set() was added in #1237 and also worked for undefined properties. This type of behavior (stubbing undefined props) has been explicitly disabled for sandboxes, so in order for Sinon to behave in a consistent way, we should do the same here. This change will bring normal stubs back to how it has used to be historically, and will make sandbox stubs and normal sinon stubs behave the same. It might break things for people relying on the behavior that has been present since Sinon 2.0, but it should make things more reliable going forward.
franck-romano
pushed a commit
to franck-romano/sinon
that referenced
this issue
Oct 1, 2019
This was a longer discussion that can be found in the issues sinonjs#1508, sinonjs#1552 and sinonjs#1537 - and internally amongst the core team. Support for stubbing props using get()/set() was added in sinonjs#1237 and also worked for undefined properties. This type of behavior (stubbing undefined props) has been explicitly disabled for sandboxes, so in order for Sinon to behave in a consistent way, we should do the same here. This change will bring normal stubs back to how it has used to be historically, and will make sandbox stubs and normal sinon stubs behave the same. It might break things for people relying on the behavior that has been present since Sinon 2.0, but it should make things more reliable going forward.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It would be great if Sinon fakeServer stored incoming so that it would be possible to do assertions against them.
What did you expect to happen?
// run test
expect(server.requests).to.have.length(0)
expect(server.requests[0].url).to.eql("xxx")
What actually happens
There is no server.requests!
Kind regards,
Tarjei
The text was updated successfully, but these errors were encountered: