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

2 consecutive 'when(...).thenTrow(...)' expectations crashes #403

Closed
4 tasks done
luca1226 opened this issue Jan 17, 2019 · 2 comments
Closed
4 tasks done

2 consecutive 'when(...).thenTrow(...)' expectations crashes #403

luca1226 opened this issue Jan 17, 2019 · 2 comments

Comments

@luca1226
Copy link

luca1226 commented Jan 17, 2019

The Mocha test that shows the crash

   it('should not crash', function () {
      const mock = td.func();

      // 1st expectation: a generic one
      td.when(mock(td.matchers.anything())).thenThrow(new Error('1st expectation'));

      // 2nd expectation:  a more specific one
      // => IT CRASH (the 1st expectation is executed when defining this one!!!)
      td.when(mock(400)).thenThrow(new Error('2nd expectation'));
   });

Issue

The 2nd expectation crashes because the 1st expectation is executed when defining the 2nd.

We had seen that this behavior correspond to this note: "Note that because rehearsal calls invoke the test double function, it's possible to configure a thenThrow stubbing and then accidentally trigger it when you attempt to configure subsequent stubbings or verifications. In these cases, you'll need to work around it by re-ordering your configurations or catch'ing the error."

Is it possible to add an option that prevent to invoke the test double function when configuring a subsequent one?

Environment

  • mocha
  • node -v output: 11.2.0
  • npm -v (or yarn --version) output: 6.5.0
  • npm ls testdouble (or yarn list testdouble) version: 3.9.3
@searls
Copy link
Member

searls commented Jan 23, 2019

As you pointed out from having read the note above, what the above code does is not yet supported by the library. I imagine what would be needed is some kind of td.disable(someFunc) API that allowed calls to be stubbed/verified without inadvertently invoking the prior stubbings of someFunc, followed by a td.enable(someFunc) API to enable it.

This would be a pretty significant code change. I'm open to it if it doesn't add a large maintenance burden, but I don't think this is a common enough case for me to invest the time to implement it.

What I'd do in your shoes is just do a single stubbing with a custom stubbing thenDo:

td.when(mock(), {ignoreExtraArgs: true}).thenDo(code => {
  if (code === 400) {
    throw new Error('2nd expectation')
  } else {
    throw new Error('1st expectation')
  } 
});

@searls searls closed this as completed Jan 23, 2019
@luca1226
Copy link
Author

Yes, thanks for your reply, you are right,

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