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.

Sign up for GitHub

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

Jump to bottom

Add createStubInstance header in stubs.md #2576

Merged
merged 1 commit into from
Sep 10, 2024
Merged

Add createStubInstance header in stubs.md #2576

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions docs/release-source/release/stubs.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,6 +90,8 @@ Note that it's usually better practice to stub individual methods, particularly

Stubbing individual methods tests intent more precisely and is less susceptible to unexpected behavior as the object's code evolves.

#### `var stubInstance = sinon.createStubInstance(MyConstructor, overrides);`

If you want to create a stub object of `MyConstructor`, but don't want the constructor to be invoked, use this utility function.
Comment on lines +93 to 95
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe expose the fact that this method really is part of the sandbox? As in sandbox.createStubInstance.... Otherwise people might mix both sinon and sandbox invocations in the same file, I think.

Whatcha think?

Copy link
Contributor Author

@DanKaplanSES DanKaplanSES Jan 10, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

@fatso83 Yeah I wasn't even aware of that. Here's my knee-jerk thought: on this line, I think changing sinon to sandbox might confuse the reader more than it informs them: some readers may not know what sandbox is (yet) and assume they can't call this method on sinon. Maybe that's a good thing, but the sandbox docs say:

Unless you have a very advanced setup or need a special configuration, you probably only need to use that one in your tests for easy cleanup.

This could be far-fetched, but they might extrapolate that to mean createStubInstance is only for "very advanced setup or need a special configuration," too. For all I know, that's the intended interpretation, but I'm assuming it's not. I'm assuming it's used more often than non-sinon sandboxes.

That said, I do think this is useful information. Maybe it could be added as a detail below the header or in the link added by #2577 ?

I don't feel that strongly about anything I've said above: if you disagree with my take, I'm happy to make your suggested change.

Copy link
Contributor

Choose a reason for hiding this comment

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

What about keeping the sinon.create... bits, but link to the sandbox.md docs for more elaborate examples?


```javascript
Expand Down