From 55a014680e4e8577c697c48b229f4b77c9cb7f2a Mon Sep 17 00:00:00 2001 From: Tamas Balog Date: Wed, 27 Sep 2023 08:38:18 +0200 Subject: [PATCH 1/2] Add Frequently Asked Questions page --- _data/doc-categories.yml | 1 + _docs/frequently-asked-questions.md | 26 ++++++++++++++++++++++++++ 2 files changed, 27 insertions(+) create mode 100644 _docs/frequently-asked-questions.md diff --git a/_data/doc-categories.yml b/_data/doc-categories.yml index c1787f6d..3a55209f 100644 --- a/_data/doc-categories.yml +++ b/_data/doc-categories.yml @@ -6,6 +6,7 @@ setup: - quickstart/java-junit - download-and-installation - getting-started + - frequently-asked-questions standalone: title: WireMock Standalone diff --git a/_docs/frequently-asked-questions.md b/_docs/frequently-asked-questions.md new file mode 100644 index 00000000..89f8346b --- /dev/null +++ b/_docs/frequently-asked-questions.md @@ -0,0 +1,26 @@ +--- +layout: docs +title: Frequently Asked Questions +meta_title: "Frequently Asked Questions in WireMock" +description: > + Frequently asked questions and best practices regarding anything WireMock. +--- + +## Frequently Asked Questions + +Here you can find answers to questions in various areas of WireMock, providing recommendations and best practices for different challenges. + +### How to manage many mocks across different use cases and teams? + +This question is valid especially when it is getting difficult to keep track of what test case(s) a particular mock was meant for. + +#### Potential solutions +- Create your stubs (or most of them at least) in the test cases themselves, then [reset them](../stubbing/#reset) each time. +- Use the [`metadata` element](../stub-metadata/) in the stub data to tag stubs with info relating them to specific test cases. + +#### Potential solutions for WireMock standalone +- Use configuration-as-code, and store your definitions in a repository. You can have a hierarchical structure of Mappings and Files to specify teams. + - Disabling the modifying APIs after moving to configuration-as-code is also highly recommended, so that teams cannot break each other's mocks. +- Introduce "subprojects" by having each app/team to use `$WIREMOCK_URL/$PROJECT_ID` or even `$WIREMOCK_URL/$TEAM_ID/$PROJECT_ID`. +- Do performance monitoring for your instance, because a single shared WireMock instance can be overloaded if multiple teams execute performance/stress tests on it. +If the workload is exceeded, you can split it into multiple instances, or consider [WireMock Cloud](https://www.wiremock.io/) which is scalable. From 6ca45fc6e32cdfc3fe60c4c228441bca341e97b6 Mon Sep 17 00:00:00 2001 From: Tamas Balog Date: Mon, 2 Oct 2023 10:07:58 +0200 Subject: [PATCH 2/2] Update the URL of the FAQ page and copy Q&As from the homepage to the FAQ page. --- _data/doc-categories.yml | 2 +- _docs/faq.md | 61 +++++++++++++++++++++++++++++ _docs/frequently-asked-questions.md | 26 ------------ 3 files changed, 62 insertions(+), 27 deletions(-) create mode 100644 _docs/faq.md delete mode 100644 _docs/frequently-asked-questions.md diff --git a/_data/doc-categories.yml b/_data/doc-categories.yml index 3a55209f..c8e66127 100644 --- a/_data/doc-categories.yml +++ b/_data/doc-categories.yml @@ -6,7 +6,7 @@ setup: - quickstart/java-junit - download-and-installation - getting-started - - frequently-asked-questions + - faq standalone: title: WireMock Standalone diff --git a/_docs/faq.md b/_docs/faq.md new file mode 100644 index 00000000..c69e5a51 --- /dev/null +++ b/_docs/faq.md @@ -0,0 +1,61 @@ +--- +layout: docs +title: Frequently Asked Questions +meta_title: "Frequently Asked Questions in WireMock" +description: > + Frequently asked questions and best practices regarding anything WireMock. +--- + +Here, you can find information about what API mocking and WireMock are, as well as recommendations and best practices for different challenges in various areas of WireMock. + +## API mocking and WireMock as a service + +### What is WireMock? + +WireMock is a free API mocking tool that can be run as a standalone server, or in a hosted version via the [WireMock Cloud](https://wiremock.io/) managed service. + +### What is API mocking? + +API mocking involves creating a simple simulation of an API, accepting the same types of request and returning identically structured responses as the real thing, +enabling fast and reliable development and testing. + +### When do you need to mock APIs? + +API mocking is typically used during development and testing as it allows you to build your app without worrying about 3rd party APIs or sandboxes breaking. +It can also be used to rapidly prototype APIs that don’t exist yet. + +### How do you create an API mock? + +WireMock supports several approaches for creating mock APIs - in code, via its REST API, as JSON files and by recording HTTP traffic proxied to another destination. + +### What makes WireMock unique? + +WireMock has a rich [matching system](../request-matching/), allowing any part of an incoming request to be matched against complex and precise criteria. +Responses of any complexity can be dynamically generated via the Handlebars based templating system. +Finally, WireMock is easy to integrate into any workflow due to its numerous [extension points](../extending-wiremock/) and comprehensive APIs. + +### Is WireMock open source? + +Yes, WireMock is a completely open source API mocking tool [GitHub repository](https://github.com/wiremock/wiremock). +If you’re looking for a hosted version of WireMock, check out [WireMock Cloud](https://wiremock.io/). + +### Is WireMock a free service? + +WireMock is completely free under the Apache 2.0 license. + +## Technical questions + +### How to manage many mocks across different use cases and teams? + +This question is valid especially when it is getting difficult to keep track of what test case(s) a particular mock was meant for. + +#### Potential solutions +- Create your stubs (or most of them at least) in the test cases themselves, then [reset them](../stubbing/#reset) each time. +- Use the [`metadata` element](../stub-metadata/) in the stub data to tag stubs with info relating them to specific test cases. + +#### Potential solutions for WireMock standalone +- Use configuration-as-code, and store your definitions in a repository. You can have a hierarchical structure of Mappings and Files to specify teams. + - Disabling the modifying APIs after moving to configuration-as-code is also highly recommended, so that teams cannot break each other's mocks. +- Introduce "subprojects" by having each app/team to use `$WIREMOCK_URL/$PROJECT_ID` or even `$WIREMOCK_URL/$TEAM_ID/$PROJECT_ID`. +- Do performance monitoring for your instance, because a single shared WireMock instance can be overloaded if multiple teams execute performance/stress tests on it. +If the workload is exceeded, you can split it into multiple instances, or consider [WireMock Cloud](https://www.wiremock.io/) which is scalable. diff --git a/_docs/frequently-asked-questions.md b/_docs/frequently-asked-questions.md deleted file mode 100644 index 89f8346b..00000000 --- a/_docs/frequently-asked-questions.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -layout: docs -title: Frequently Asked Questions -meta_title: "Frequently Asked Questions in WireMock" -description: > - Frequently asked questions and best practices regarding anything WireMock. ---- - -## Frequently Asked Questions - -Here you can find answers to questions in various areas of WireMock, providing recommendations and best practices for different challenges. - -### How to manage many mocks across different use cases and teams? - -This question is valid especially when it is getting difficult to keep track of what test case(s) a particular mock was meant for. - -#### Potential solutions -- Create your stubs (or most of them at least) in the test cases themselves, then [reset them](../stubbing/#reset) each time. -- Use the [`metadata` element](../stub-metadata/) in the stub data to tag stubs with info relating them to specific test cases. - -#### Potential solutions for WireMock standalone -- Use configuration-as-code, and store your definitions in a repository. You can have a hierarchical structure of Mappings and Files to specify teams. - - Disabling the modifying APIs after moving to configuration-as-code is also highly recommended, so that teams cannot break each other's mocks. -- Introduce "subprojects" by having each app/team to use `$WIREMOCK_URL/$PROJECT_ID` or even `$WIREMOCK_URL/$TEAM_ID/$PROJECT_ID`. -- Do performance monitoring for your instance, because a single shared WireMock instance can be overloaded if multiple teams execute performance/stress tests on it. -If the workload is exceeded, you can split it into multiple instances, or consider [WireMock Cloud](https://www.wiremock.io/) which is scalable.