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

Default wrongArgs implementation for README #91

Closed
joebowbeer opened this issue Dec 12, 2021 · 2 comments
Closed

Default wrongArgs implementation for README #91

joebowbeer opened this issue Dec 12, 2021 · 2 comments

Comments

@joebowbeer
Copy link

joebowbeer commented Dec 12, 2021

Thanks for creating this!

I'm familiar with this technique in sinon, and I find that verifying arguments at the call site often results in better tests than verifying them after execution.

In trying to replicate the patterns I've used in sinon, it wasn't clear from the README how to write the default failing function that handles the wrong-args case.

I include my implementation below in hopes that you include it or something similar in your README:

// A default implementation that fails
const wrongArgs = (...args: any[]) => {
  throw new Error(`Wrong args: ${JSON.stringify(args, null, 2)}`);
};

when(fn)
  .mockImplementation(wrongArgs)
  .calledWith(correctArgs)
  .mockReturnValue(expectedValue);
@timkindberg
Copy link
Owner

Thanks for the idea! That's pretty cool.

I'm starting to hate the README actually, it's getting very busy and hard to find things.

Also I'm starting to think the default behavior needs to be a more explicit abstraction, like maybe rename itwhen(fn).defaultImplementation() vs what it is today.

@joebowbeer
Copy link
Author

by the way, I've replaced JSON.stringify with util.inspect in my current implementation of this function

// A default implementation that fails the test
export function wrongArgs(...args: any[]) {
  throw new Error(`Wrong args: ${inspect(args)}`)
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants