Is there a way to reset the mocks?

[douglascvas]

Whould be awesome if there was a way to reset the mocks.

[DillonSykes]

Completely agree this should be a staple to any mocking lib

[ffMathy]

Why not just make a new mock?

[notanengineercom]

Why not just make a new mock?

I agree on that. I could see useful reseting the call counts for example, but I can't think of a case where reseting the mocks is better than making a new one

[abdala]

Sinon has an option to reset and restore because they work with global state and that is not the case of this library.

When you create a new mock you have a completely new instance.

This is what I usually do:

let mock: SubstituteOf<Calculator>;

beforeEach(() => {
   mock = Substitute.for<Calculator>();
});

[ffMathy]

Global state is just hard to test in general and should be avoided when possible. I feel like adding this feature is just making it easier to treat the symptom and not fix the problem.

But maybe that's just me?

Can't you provide a function for resetting your global state? Or refactor and avoid it all together?

[ffMathy]

Closing until we hear a reply.

[vigie]

Here is a use case that has nothing to do with global state:

Let's say I'm using Substitue to mock a dependency and give it some default behavior. This default behavior is appropriate for 99% of my tests so I have it as part of my common test setUp() routine, which is also doing a lot of other common setup before each test. But for one of my tests I need this substitute to do something different. I still want to be able to call setUp because of all the other useful shared code it contains, but now I want to override the assigned default behavior of that mock.

Sketch:

function setUp() {
   const fooSub = Substitute.for<Foo>();
   fooSub.bar(Arg.any()).returns('hello');
   ...
   ... // Here I am setting up a dozen other common mocks and behaviors
   ...
   return {
      fooSub,
      // and all the others
   };
}

it('tests the weird corner case', () => {
   const { fooSub } = setUp();
   // Need fooSub to do something a bit different for this test.
   fooSub.bar(Arg.any()).returns('world'); // <-- won't work, can't update the behavior.
   ...
});

[ffMathy]

Alright, that actually makes a lot of sense.

Perhaps we should start support this: https://nsubstitute.github.io/help/configure/ or something similar.

We would need to make it more JavaScript friendly though, as Configure might actually be a real name that people use for their methods.

@notanengineercom got an idea?

[notanengineercom]

Ahh this is great. I experimented with a solution similar to .Configure, but the behaviour was different. I like your proposition way better 👍
About the naming, from what I read, Configure() is only used to modify the mocks for a method. So something along the lines of configureMockFor(), configureSubstitute()...

[pheintzelman]

I'm a bit late to this conversation. This is also something I would like to see also. In other mocking libraries I have used they solved this by having having Substitute.for() return a handle, something like const calculator = Substitute.for() => {add:{returns...}..., mock} where mock is what it is returning now.

Passing calculator.mock into the dependency injection is not a big deal. This keeps test clean as you won't need to call config everywhere.

[notanengineercom]

Passing calculator.mock into the dependency injection is not a big deal

I'm sorry to disagree on that sentence. I think one of the main principles of this library is both being able to setup and use the mock object as the dependency to be injected. But we are well aware of the limitations the current design enforces. Nonetheless, I think your comment brought in a new (and maybe better) idea to solve the mock reassignment problem. More info will follow soon.