From a6c18706b51c0d9c8798462f8d9ad9323877f2df Mon Sep 17 00:00:00 2001 From: Stef Heyenrath Date: Sat, 7 Oct 2017 17:37:30 +0200 Subject: [PATCH] Updated Scenarios and States (markdown) --- Scenarios-and-States.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Scenarios-and-States.md b/Scenarios-and-States.md index f1a554e..e7eb4fa 100644 --- a/Scenarios-and-States.md +++ b/Scenarios-and-States.md @@ -1,6 +1,6 @@ # Scenarios -WireMock.net supports state via the notion of scenarios. A scenario is essentially a state machine whose states can be arbitrarily assigned. Stub mappings can be configured to match on scenario state, such that stub A can be returned initially, then stub B once the next scenario state has been triggered. +WireMock.Net supports state via the notion of scenarios. A scenario is essentially a state machine whose states can be arbitrarily assigned. Stub mappings can be configured to match on scenario state, such that stub A can be returned initially, then stub B once the next scenario state has been triggered. For example, suppose we’re writing a to-do list application consisting of a rich client of some kind talking to a REST service. We want to test that our UI can read the to-do list, add an item and refresh itself, showing the updated list.