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

.rejects doesn't match documentation #2580

Closed
mroderick opened this issue Jan 10, 2024 · 2 comments
Closed

.rejects doesn't match documentation #2580

mroderick opened this issue Jan 10, 2024 · 2 comments
Labels
Bug good first issue Help wanted semver:major changes will cause a new major version

Comments

@mroderick
Copy link
Member

mroderick commented Jan 10, 2024

The documentation for stub.rejects specifies

stub.rejects("TypeError");
Causes the stub to return a Promise which rejects with an exception of the provided type.

However, that is incorrect.

The returned value from that example, will give you an Error object, with the name property set to the value of the first argument.

However, the desired behaviour (according to the documentation) should be more like this:

// create a stub that rejects with an `Error` with a blank message
const stub1 = sinon.stub().rejects();
// create a stub that rejects with a user supplied reason
const reason = "The pie is a lie";
const stub2 = sinon.stub().rejects(reason);
// create a stub that rejects with exactly the error instance provided
const myError = new Error(reason);
const stub3 = sinon.stub().rejects(myError);

// example
const applePieError = new RangeError("The apple pie is a lie");
const stub4 = sinon.stub().rejects(applePieError);

try {
    await stub4();
} catch (error) {
    console.log(error === applePieError);
    // => true
}
@mroderick mroderick added Bug Help wanted good first issue semver:major changes will cause a new major version labels Jan 10, 2024
@fatso83
Copy link
Contributor

fatso83 commented Jan 11, 2024

I actually do not know what is meant here. Is the implementation wrong or the documentation? What behavior should we aim for? What is chosen should at least be consistent, ref confusions in #1679 and alike.

@mroderick
Copy link
Member Author

Closing this issue in favour of continuing discussion in #1679

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug good first issue Help wanted semver:major changes will cause a new major version
Projects
None yet
Development

No branches or pull requests

2 participants