Skip to content
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

fixes issue #1368 by adding stub#resolvesThis #1517

Merged
merged 3 commits into from Aug 10, 2017

Conversation

HugoMuller
Copy link
Contributor

Purpose (TL;DR) - mandatory

This PR fixes issue #1368.

Background (Problem in detail) - optional

The feature request was to make stub able to resolve a promise with its own context, like stub#returnsThis would do synchronously.

Solution - optional

Simply add the method stub#resolvesThis, which is the async version of stub#returnsThis.

How to verify - mandatory

  1. Check out this branch (see github instructions below)
  2. npm install
  3. npm test

resolvesThis: function resolvesThis(fake) {
fake.resolveThis = true;
fake.resolve = false;
fake.reject = false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO we should keep this consistent with other behaviors, such as rejects, which also sets many other flags, as you can see here. Even though this is enough to make it work, I think that by keeping the whole API consistent when it comes to flagging fakes is extremely important.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you created the wrong link? It just points back to your comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I can set returnValueDefined and exception flags to false to keep consistency. Do you think some other flags need to be turned off?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fatso83 I think that link only works inside the files tab. When I click it inside of it the link works.

Basically I think the following flags should be set:

  • fake.returnValue
  • fake.returnValueDefined
  • fake.exception

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay now resolves, rejects and resolvesThis all act on the same flags.
I set returnValue to undefined as the stub resolves with itself.
Is it okay by you?

@lucasfcosta
Copy link
Member

Hi @HugoMuller, thanks for this awesome Pull Request!

I really liked your tests and your clean code. It works, indeed and it is an extremely important feature IMO. I just had a comment regarding the flags being set when the resolvesThis behavior is used.

Please let me know if you disagree with anything or if you have any further doubts.

I'm looking forward to being able to merging this as soon as everyone approves it.

Thanks again for your work 😄

Copy link
Member

@mroderick mroderick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great PR! Thank you.

Just a few minor comments from me

var strictMode = (function () {
return this;
}()) === undefined;
if (strictMode) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure a conditional for strict mode is necessary:

  • Sinon's source is meant to be ES5.1, strict mode and expects to run in engines that supports that.
  • The test file has use strict; at the top.

If for some reason, someone decides to run the tests in non-strict mode or in engines that doesn't support that, then I think the tests should be allowed to fail.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, the tests I wrote are very similar to those written for returnsThis.
So the same logic applies here. But if this one does not make sense, then I can remove it.
Same remark for the unclear expectations.

});
}

it("stub respects call", function () {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this expectation be more specific, to make it easier to understand what "respects call" means?

});
});

it("stub respects apply", function () {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this expectation be more specific, to make it easier to understand what "respects apply" means?

@@ -2171,6 +2230,16 @@ describe("stub", function () {
refute.defined(instance.stub());
});

it("cleans 'resolvesThis' behavior", function () {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is generally better to be very specific when writing expectations, especially in codebases with distributed contributors. Generic expectations often lead to readers trying to derive the intent from the implementation of the test. If there's a mistake in the implementation, then the reader is likely to end up with an incorrect understanding of then intended behaviour.

I would suggest rewriting the expectation to something like this:

it("cleans 'resolvesThis' behavior using stub.resetBehavior", function () {
it("calls stub's resetBehavior method to clean behavior", function () {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll fix these expectations. Thanks for the suggestions.

stub#resolvesThis sets some more flags
better unit tests expectations to improve readability
remove the "strictMode" test that probably does not make sense
@mroderick
Copy link
Member

👍

between resolves, rejects and resolvesThis
@fatso83 fatso83 merged commit 3df68a7 into sinonjs:master Aug 10, 2017
@HugoMuller HugoMuller deleted the issue-1368-resolvesThis branch August 10, 2017 07:16
@mroderick mroderick added the semver:minor changes will cause a new minor version label Aug 10, 2017
franck-romano pushed a commit to franck-romano/sinon that referenced this pull request Oct 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semver:minor changes will cause a new minor version
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants