Stay in Current State for specified number of requests #288

New Issue

adam · 2025-12-29T08:25:28+01:00

adam commented

2025-12-29 08:25:28 +01:00

Originally created by @shoaibshakeel381 on GitHub (Jul 30, 2020).

Hey guy,s I need to write mocks such that a request keeps faulting for a given number of time before it can succeed. I know that I can use Scenarios for this.

But there's a problem. Let's suppose I want to fault my request 2 times before succeeding on 3rd attempt. So I have to write three mocks where flow would be like this:

-- 1st Mock:
    -- Set next state to "fail"
    -- Fail request

-- 2nd Mock:
    -- When current state is "fail"
    -- Set next state to "pass"
    -- Fail request

-- 3rd Mock:
    -- When current state is "pass"
    -- Pass request

We can see that first 2 states are just doing same thing. So my question is this: Is it possible to build a mock which stay in its current state for a given number of time, before switching to next one. So my mocks would be like below:

-- 1st Mock:
    -- Set next state to "pass" ONLY after 2 requests
    -- Fail request

-- 2nd Mock:
    -- When current state is "pass"
    -- Pass request

Originally created by @shoaibshakeel381 on GitHub (Jul 30, 2020). Hey guy,s I need to write mocks such that a request keeps faulting for a given number of time before it can succeed. I know that I can use Scenarios for this. But there's a problem. Let's suppose I want to fault my request 2 times before succeeding on 3rd attempt. So I have to write three mocks where flow would be like this: ``` -- 1st Mock: -- Set next state to "fail" -- Fail request -- 2nd Mock: -- When current state is "fail" -- Set next state to "pass" -- Fail request -- 3rd Mock: -- When current state is "pass" -- Pass request ``` We can see that first 2 states are just doing same thing. So my question is this: **Is it possible to build a mock which stay in its current state for a given number of time, before switching to next one.** So my mocks would be like below: ``` -- 1st Mock: -- Set next state to "pass" ONLY after 2 requests -- Fail request -- 2nd Mock: -- When current state is "pass" -- Pass request ```

adam added the feature label 2025-12-29 08:25:28 +01:00

adam closed this issue

2025-12-29 08:25:28 +01:00

adam commented

2025-12-29 08:25:28 +01:00

@StefH commented on GitHub (Jul 30, 2020):

@shoaibshakeel381

Probably the interface can look like:

var server = WireMockServer.Start();

server
                .Given(Request.Create().WithPath(path).UsingGet())
                .InScenario("S")
                .WillSetStateTo("bar")
                .WhenMatchingCountEquals(2)
                .RespondWith(Response.Create().WithBody("Scenario S, Setting State bar"));

server
                .Given(Request.Create().WithPath(path).UsingGet())
                .InScenario("S")
                .WhenStateIs("bar")
                .RespondWith(Response.Create().WithBody("Scenario S, State bar"));

or

var server = WireMockServer.Start();

server
                .Given(Request.Create().WithPath(path).UsingGet())
                .InScenario("S")
                .WillSetStateTo("bar", 2) // 2 = matching count
                .RespondWith(Response.Create().WithBody("Scenario S, Setting State bar"));

server
                .Given(Request.Create().WithPath(path).UsingGet())
                .InScenario("S")
                .WhenStateIs("bar")
                .RespondWith(Response.Create().WithBody("Scenario S, State bar"));

@StefH commented on GitHub (Jul 30, 2020): @shoaibshakeel381 Probably the interface can look like: ``` c# var server = WireMockServer.Start(); server .Given(Request.Create().WithPath(path).UsingGet()) .InScenario("S") .WillSetStateTo("bar") .WhenMatchingCountEquals(2) .RespondWith(Response.Create().WithBody("Scenario S, Setting State bar")); server .Given(Request.Create().WithPath(path).UsingGet()) .InScenario("S") .WhenStateIs("bar") .RespondWith(Response.Create().WithBody("Scenario S, State bar")); ``` or ``` c# var server = WireMockServer.Start(); server .Given(Request.Create().WithPath(path).UsingGet()) .InScenario("S") .WillSetStateTo("bar", 2) // 2 = matching count .RespondWith(Response.Create().WithBody("Scenario S, Setting State bar")); server .Given(Request.Create().WithPath(path).UsingGet()) .InScenario("S") .WhenStateIs("bar") .RespondWith(Response.Create().WithBody("Scenario S, State bar")); ``` ```

adam commented

2025-12-29 08:25:29 +01:00

@shoaibshakeel381 commented on GitHub (Jul 30, 2020):

@StefH I would suggest second approach. Here's why:

This count is highly related to WillSetStateTo() so it would make sense to keep both values in one atomic operation
WhenMatchingCountEquals() can be misplaced like this:

server
                .Given(Request.Create().WithPath(path).UsingGet())
                .WhenMatchingCountEquals(2)
                .InScenario("S")
                .WillSetStateTo("bar")
                .RespondWith(Response.Create().WithBody("Scenario S, Setting State bar"));

which is not very readable. It can even be used like this:

server
                .Given(Request.Create().WithPath(path).UsingGet())
                .WhenMatchingCountEquals(2)
                .RespondWith(Response.Create().WithBody("Scenario S, Setting State bar"));

which doesn't make sense.

@shoaibshakeel381 commented on GitHub (Jul 30, 2020): @StefH I would suggest second approach. Here's why: - This count is highly related to `WillSetStateTo()` so it would make sense to keep both values in one atomic operation - `WhenMatchingCountEquals()` can be misplaced like this: ```c# server .Given(Request.Create().WithPath(path).UsingGet()) .WhenMatchingCountEquals(2) .InScenario("S") .WillSetStateTo("bar") .RespondWith(Response.Create().WithBody("Scenario S, Setting State bar")); ``` which is not very readable. It can even be used like this: ```c# server .Given(Request.Create().WithPath(path).UsingGet()) .WhenMatchingCountEquals(2) .RespondWith(Response.Create().WithBody("Scenario S, Setting State bar")); ``` which doesn't make sense.

adam commented

2025-12-29 08:25:29 +01:00

@StefH commented on GitHub (Aug 1, 2020):

@shoaibshakeel381
Can you try preview version WireMock.Net.1.2.16-ci-13650.nupkg from MyGet ? (https://github.com/WireMock-Net/WireMock.Net/wiki/MyGet-preview-versions)

@StefH commented on GitHub (Aug 1, 2020): @shoaibshakeel381 Can you try preview version `WireMock.Net.1.2.16-ci-13650.nupkg` from MyGet ? (https://github.com/WireMock-Net/WireMock.Net/wiki/MyGet-preview-versions)

adam commented

2025-12-29 08:25:29 +01:00

@shoaibshakeel381 commented on GitHub (Aug 1, 2020):

I tested this preview version on my tests and it worked flawlessly. Great job.

@shoaibshakeel381 commented on GitHub (Aug 1, 2020): I tested this preview version on my tests and it worked flawlessly. Great job.

adam commented

2025-12-29 08:25:29 +01:00

@StefH commented on GitHub (Aug 1, 2020):

I'll create an official version within some time.

https://github.com/WireMock-Net/WireMock.Net/pull/495

@StefH commented on GitHub (Aug 1, 2020): I'll create an official version within some time. https://github.com/WireMock-Net/WireMock.Net/pull/495

Sign in to join this conversation.

Branches Tags

master

mime-part-matcher

version-2.x

MappingSerializer

1341-mapping-json

stef-aspire-tests-updates

bug/973-TinyMapper

bug/1149-AppendGuidToSavedMappingFile

feature/1150-DockerImageVersion

61

stef-1108

stef-1097

stef-1083-MessageOptions_Type_Conflict

stef-1062-logger

stef-IgnoreOpenApiErrors

stef-928-TypeLoadException-FluentAssertions-net472

nunit

stef-849

stef-847-regex-questionmark

http_verb

WireMockServerContext

webapp

ai

CommandLineArgumentsParser

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/WireMock.Net#288