-
-
Notifications
You must be signed in to change notification settings - Fork 771
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
Add getters/setters stub behaviors new API #1297
Conversation
Good stuff. I implemented most of the stuff you mentioned in 1258 yesterday, which included most of this, but not the part where you modify the stub in the outer module to keep the reference to the original object. That was the missing part of the puzzle I was too tired to find yesterday 😅 Using your other suggestions I guess most things are covered, and AFAIK this should also work for sandboxes. I think we could easily modify this to also support restoring, if we store the original property definition ( One thing the current approach does not support, AFAI can see, is support the chaining we were discussing. AFAIK, each invocation of |
@lucasfcosta this branch needs a rebase. How far would you guess you are with this? Any chance of completing it soon? |
As said above he will be unable to complete this until he gets back in another two weeks. I did some of it, but won't have time until next weekend. |
My apologies, I was clearly not paying attention |
Do we want to wait another two weeks for the 2.0 release? Can't this be in 2.1? Or is it breaking? |
I'd say we ship this MF. And bump the minor version once we have this.
7. mar. 2017 1.44 p.m. skrev "Christian Johansen" <notifications@github.com
…:
Do we want to wait another two weeks for the 2.0 release? Can't this be in
2.1? Or is it breaking?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#1297 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAluXNSwZoVrELWFpHVsczf2q0l_6hdDks5rjVEhgaJpZM4MMN3z>
.
|
If I understood it correctly, then it we have introduced a breaking change, that has the potential of getting fixed by this PR. While I am keen to ship, I don't think waiting a week or two is going to make that big a difference. |
Hi friends, I just got back from London, I'll be able to work on this again. If you have any related PRs or issues that happened in this time but were not linked to this issue, please let me know. Also, when it comes to releasing this change, I think we should do this ASAP, since this PR adds a feature that has been removed due to the deprecation of the old API (even though it still exists on the codebase). I'll try to work on this tonight and tomorrow, but I can't guarantee I'll be able to finish it fast since we've got lots of edge cases to cover and checks to remove. I'd like to be careful when removing some of these checks because I want to enable this feature without damaging other restrictions and user feedback. My main concern are the |
Hi friends, this one is done! I will not edit the first post to keep the history of changes and previous explanation. Here goes a description of the changes I've just done. BackgroundSo, as I've explained on the first post of this PR we still needed to decide how we were going to wrap function properties. The old approach tried to detect non-function properties and then trigger specific behavior for it. Due to that fact we were not able to wrap function properties, because then we would still call the old We also needed a restore method to get the old descriptor back in its place if needed. SolutionInstead of changing Also, there's no problem in always using Finally I added a simple restore method to the I also added a few new tests for that. They ensure this change is compliant with the following specs:
Other Details
PS.: Does anyone know why coveralls is failing? I've seen #1319 but I can't see why it happens on every PR. Sorry for taking so long to continue this. If you need any further changes I'll be more than happy to do them. |
6164085
to
bf2a170
Compare
bf2a170
to
ad58467
Compare
We are doing this for free. Don't feel bad :-) The code looks fine, so I am merging this. Coveralls does not come with any good docs, so I am not sure why it fails, but I am guessing it simply fails the build if the coverage drops beyond some threshold. Looking at some of the non-covered code Coveralls complains about, it seems that it has to do with non-ES5 code which is not triggered. We no longer support non-ES5 browsers, so that code could well be scrapped. |
And with that merge done we are now in ready-to-publish-Sinon-2-land, @sinonjs/sinon-core 🎉 |
@fatso83 yayyy! Congrats 😃 Also, I was thinking about refactoring |
@lucasfcosta sure, go ahead, but it won't stop us from releasing 2.0. |
@cjohansen will you do the honours? |
Improvements are always welcome 👍 |
This pull request is now complete. Please see this comment to read about the new changes.
Purpose (TL;DR)
This aims to add
get/set
stubbing features for #1258.I also added some tests for it (supporting only the current state of this PR, not the whole feature).
Background
As I've said in the previous section, given the new API and deprecation of
stubDescriptor
(#1239) we should have a new API for setting getter and setter stubs.Right now it's only allowing us to define getters and setters for non-function properties. Which I admit is not that useful as if it allowed stubbing getters and setters for functions too.
The reason I'm opening an incomplete PR is both to have your feedback on the current work and also because I'll be traveling tomorrow so I won't have time to work on this for the next two weeks so I will leave this here in case someone wants to continue this work (sorry for that!).
Solution
Since this solution is partial I'll explain what I've done until now and the problems I've faced.
First of all I needed to store a reference to the root object and the original property name which we're adding this stub to in this line. I only do that when someone passes a non-function property in order to avoid calling
wrapMethod
which ends up throwing an error when we pass non-function properties to it. We might want to look forward to allow it to wrap non-function properties too in order to fully accomplish this PR's goal.The reason I needed to import
getPropertyDescriptor
is to avoid triggering existing getters when doing our property type checks.Then finally I have just added two new behaviors which you can see here and here. These are the methods responsible for adding the getter/setter replacements to the desired property on the object we're stubbing. It simply gets the reference to the root object and the property's name and defines a new descriptor for it.
Known Issues With This Approach:
restore
these getters/settersAlso, @fatso83 talked to me about not having the stub available anymore when retrieving a property if we stub its property descriptor. I haven't thought about this when I was talking to him, but since the behavior methods return
this.chain()
it would not be a problem, we would just need to assign the result of calling theget
orset
method to a variable and then use it to manage our stub.Things we might wanna do for this to be complete:
wrapMethod
to wrap non-function properties in order for us to be able to stub themIn a nutshell: if we make
wrapMethod
work for this use case it would be perfect because then we could use it and accomplish our goal without too much branching.How to verify - mandatory
npm install
npm test
-> This will run the newly created testsFeel free to clone my fork and continue your work from there if you want to, this is just a proof of concept and a way of sharing what I've thought as I was talking to @fatso83 this morning.
Sorry again for not being able to finish this, I hope this PR helps you deciding what to do.