Unexpected state API behaviour around unset state

The following code would appear to leave the state unchanged. But after this is matched in runtime. The state will be reset to “nothing” like it had never been set.

            _server
                .Given( Request.Create().UsingGet().WithPath( new ExactMatcher("/StateUnchanged")))
                .InScenario("default")
                .WhenStateIs("State2")
                .RespondWith( Response.Create().WithBody("State reset to nothing"));

Leading to the following code that is unnecessarily verbose. Particularly with a fluent API. Where the intention seems to underspecify a mock API. And leave the tool to make educated choices.

            _server
                .Given( Request.Create().UsingGet().WithPath( new ExactMatcher("/StateUnchanged")))
                .InScenario("default")
                .WhenStateIs("State2")
                .WillSetStateTo("State2")
                .RespondWith( Response.Create().WithBody("State is still State2"));

[arturohernandez10]

@StefH

Awesome!! I like this library, that comment may have spared me from some confusion. It may help someone else. Next time I use this tool, I’ll create an extension method as a shortcut for .WhenStateIs("x").WillSetStateTo("x") and I’ll post it here if anyone prefers to use it.

Thanks!

[StefH]

@arturohernandez10 Now I understand your question.

Actually, your question looks a lot like this issue : https://github.com/WireMock-Net/WireMock.Net/issues/494

Which was solved by adding an times parameter to the WillSetStateTo method: IRespondWithAProvider WillSetStateTo(string state, int? times = 1);

In your case, you can set the value for the times to Int32.MaxValue.

I think this solves your issue. Can you take a look and test ?

Wiki has been updated : The number of times this match should be matched before the state will be changed to the specified one. Default value is 1.