add workshop instructions

.gitmodules

@@ -0,0 +1,3 @@
+[submodule "lab-instructions/themes/learn"]
+	path = lab-instructions/themes/learn
+	url = https://github.com/matcornic/hugo-theme-learn.git

lab-instructions/archetypes/default.md

@@ -0,0 +1,6 @@
+---
+title: "{{ replace .Name "-" " " | title }}"
+date: {{ .Date }}
+draft: true
+---
+

lab-instructions/config.toml

@@ -0,0 +1,41 @@
+baseURL = "/"
+languageCode = "en-us"
+theme = "learn"
+
+[outputs]
+home = [ "HTML", "RSS", "JSON" ]
+
+[blackfriday]
+hrefTargetBlank = true
+
+[params]
+showVisitedLinks = true
+disableBreadcrumb = false
+disableNextPrev = false
+themeVariant = "red"
+
+# you can comment out the editURL parameter once the workshop has been proofread
+editURL = "https://github.com/nmasse-itix/microcks-workshop/edit/master/lab-instructions/content/"
+
+# OpenShift Console URL (scheme, hostname and port)
+openshift_console_url="https://openshift.itix.fr:8443"
+
+# Microcks installation (scheme, hostname and port)
+microcks_url="https://microcks.app.itix.fr"
+
+# Microcks client created by default in the "microcks" realm of Keycloak
+microcks_client_id="microcks-serviceaccount"
+microcks_client_secret="30975a1b-eada-4379-89e8-99c8619462c6"
+
+# Apicurio installation (scheme, hostname and port)
+apicurio_studio_url="https://apicurio-studio.app.itix.fr"
+
+# On-site GitHub installation (scheme, hostname and port)
+github_url="https://github.com/"
+
+# Petstore API implementation, deployed twice as explained in api-backend/nodejs/README.md
+petstore_api="http://petstore-api.app.itix.fr"
+petstore_api_fixed="http://petstore-api-fixed.app.itix.fr"
+
+# The customer name (free choice)
+company = "Red Hat"

lab-instructions/content/_index.md

@@ -0,0 +1,11 @@
+---
+title: "Microcks Workshop"
+---
+
+# Welcome in this Microcks Workshop!
+
+APIs are the cornerstone of so many recent breakthroughs: from mobile applications, to the Internet of Things, to cloud computing. All those technologies expose, consume, and are built on APIs. And those APIs are a key driver for generating new revenue. Salesforce generates 50% of its revenue through APIs, Expedia generates 90% of its, and eBay generates 60% of its. With APIs becoming so central, it becomes essential to deal with Mocking and Testing. The success of your digital transformation project depends on it!
+
+This workshop presents the mocking and testing activities of the full API lifecycle management that can guide you from an idea to the realization, from the inception of an API program up to management at scale throughout your whole company.
+
+Click the big red arrow on the right side of the screen to start with a **definition of the API Lifecyle**!

lab-instructions/content/conclusion/_index.md

@@ -0,0 +1,19 @@
++++
+title = "Conclusion"
+weight = 15
+chapter = true
+pre = "<b>15. </b>"
++++
+
+### Chapter 15
+
+# Conclusion
+
+Red Hat technologies and communities can help with full API lifecycle management. The diagram below shows tools for full API lifecycle management:
+
+![Tools for the API Lifecycle](/overview/api-lifecycle/tools.png)
+
+Communities such as Apicurio and Microcks will help you with the design, mock, and tests. A whole development offering such as Red Hat Fuse, Red Hat OpenShift Application Runtimes, or Red Hat CodeReady Workspaces can help you develop reliable API back ends. Red Hat Ansible Automation can help you with the Continuous Delivery of your APIs. Red Hat Single Sign-On can help secure your APIs, and Red Hat 3scale API Management handles the rest of the API lifecycle. Last but not least, Red Hat can help you define your API strategy through a service offering: the API Model Canvas.
+
+Red Hat OpenShift Container Platform is a the core of this lifecycle, since it is the component that brings agility and makes this approach flow more easily.
+

lab-instructions/content/design/_index.md

@@ -0,0 +1,14 @@
++++
+title = "Design"
+weight = 3
+chapter = true
+pre = "<b>3. </b>"
++++
+
+### Chapter 3
+
+# Design
+
+The **Design** phase will ensure your organization uses a contract-first approach. This phase entails gathering feedback early, breaking the dependencies between projects, and reducing risks. Also, a contract-first approach is known to reduce the time to market.
+
+In the **Design** phase, you design the contract of your API and share it with your future consumers. The outcome of the **Design** phase is an API contract that describes the messages that can be exchanged with your APIs.

lab-instructions/content/design/exercise.md

@@ -0,0 +1,34 @@
+---
+title: "Exercise"
+weight: 1
+---
+
+## Craft the API contract of the ACME Petstore API!
+
+The ACME petstore is about to adopt APIs **in order to expose their catalog of pets** to the outside world. Help them design an API contract!
+
+- Open the [APICurio Studio]({{< param apicurio_studio_url >}}/apis/create)
+- Register if you are a newcomer or login if you already have an account
+- Give a name to your API (**Please add your login to the API name so that it is unique amongst all participants**)
+- Invent a nice description for your API
+- Leave the **type** to **Open API 3.0.2**
+- Select the **Petstore Example** as starting **Template**
+- Click **Create API**
+- Click **Edit API**
+
+The existing template is quite good but we will make a small change for the sake of exploring Apicurio.
+
+- Click the **/pets/{id}** path
+- Scroll down to the **Operations** section
+- Click the **DELETE** operation
+- Scroll down to the **Responses** section
+- Click the little trash icon on the right side of the screen to remove the existing responses
+- Click **Add a response**
+- Leave **200 OK** as the default response
+- Fill-in a description
+- Click **Add a media type**, leave **application/json** as the default media type and click **Add**
+- Change the return type to **Pet**
+
+Congratulations! You just designed your first API Contract in a graphical way!
+
+**To complete your understanding**, explain which method is missing in the Petstore API to have a proper CRUD API?

lab-instructions/content/iterate/_index.md

@@ -0,0 +1,13 @@
++++
+title = "Iterate"
+weight = 5
+chapter = true
+pre = "<b>5. </b>"
++++
+
+### Chapter 5
+
+# Iterate
+
+ACME found their first customers and they gave it feedback.
+Let's iterate over those feedback to improve our design!

lab-instructions/content/iterate/exercise.md

@@ -0,0 +1,67 @@
+---
+title: "Exercise"
+weight: 1
+---
+
+## Improve the API contract of the ACME Petstore API!
+
+ACME found their first customers and they gave it feedback: a method is required to **update a pet**.
+Let's add this method!
+
+Oh, there is a last minute requirement from those customers: in the mock, they would like to be able to update the pet *Zaza* to *Tata*.
+
+- Open the [APICurio Studio]({{< param apicurio_studio_url >}}/apis)
+- Open your **Petstore** API
+- Click **Edit API**
+- Start by changing the version number of your API to **1.1.0**
+- In the left pane, open the **/pets/{id}** path
+- Click **PUT** > **Add Operation**
+- Set the **Operation ID** to `updatePet`
+- Fill-in a **Summary** and a **Description**
+- Scroll down to the **Path parameters** section
+- Click **Override**
+- Add an example **that you will name "zaza"**
+- Fill-in this example with Zaza's id
+- Scroll down to the **Request body** section
+- Set the request body to **Required**
+- Add a **media type**
+- Leave **application/json** as the default **media type** and click **Add**
+- Set the type to **Pet**
+- Add an example **that you will name "zaza"**
+- Fill-in this example with the updated "Zaza" pet
+
+```json
+{"id":1,"name":"Tata","tag":"cat"}
+```
+
+- Scroll down to the **Responses** section
+- Add a **response**
+- Select **200 OK** and click **Add**
+- Fill-in the description
+- Add a **media type**
+- Leave **application/json** as the default **media type** and click **Add**
+- Set the type to **Pet**
+- Add an example **that you will name "zaza"**
+- Fill-in this example with the updated "Zaza" pet
+
+```json
+{"id":1,"name":"Tata","tag":"cat"}
+```
+
+- In the breadcrumb, click your **Petstore** API
+- Scroll down and click **Update Mock in Microcks** > **Mock API** > **OK**
+- Click **View in Microcks**
+- Unfold the **PUT /pets/{id}** operation
+- **Question:** can you see the examples you defined in Apicurio?
+- If you have access to a command line with curl installed, you can test your new mock: 
+  - Copy the mock URL given by Microcks
+  - Execute the following command:
+
+```sh
+curl -XPUT -H "Content-Type: application/json" -d '{"id":1,"name":"Tata","tag":"cat"}' https://replace.me.by/mock/url
+```
+
+**To complete your understanding**, explain:
+
+- why we asked you to name all your examples **zaza**?
+- what would be required to mock the PUT operation to rename **Maki** (pet number 3) to **Sushi**?

lab-instructions/content/mock/_index.md

@@ -0,0 +1,12 @@
++++
+title = "Mock"
+weight = 4
+chapter = true
+pre = "<b>4. </b>"
++++
+
+### Chapter 4
+
+# Mock
+
+In the **Mock** phase, you will define meaningful payload examples of your APIs and try to refine your specifications with business expectations for common and edge cases. Those examples are then turned into a live mock that can be exposed to your first consumers. “Business expectations” entail everything that cannot be specified using a formal schema. An example could be that when querying items by status, all returned items must have the desired status. You could also think about mutually exclusive options or dependencies between fields: for example, if the field companyName is set, then the field accountType needs to be “enterprise.”

lab-instructions/content/mock/exercise.md

@@ -0,0 +1,27 @@
+---
+title: "Exercise"
+weight: 1
+---
+
+## Expose a Mock of the ACME Petstore API!
+
+As the ACME Petstore API matures, the sales representative of the ACME Petstore already found his first customers. In this exercise, you will have to **expose a mock of the ACME Petstore API** so that future customers can start their implementation ahead and provide feedback early.
+
+- Open the [APICurio Studio]({{< param apicurio_studio_url >}}/apis)
+- Open your **Petstore** API
+- Select **Mock with Microcks**
+- Click **Mock API**
+- Click **OK**
+- Click **View in Microcks**
+- In the **Microcks UI**, unfold the four operations and discover the generated mock URLs
+- Copy the URL of the **GET /pets** operation and paste it in a new tab of your web browser
+- **Question:** How many pets are there?
+- Copy the URL of the **GET /pets/{id}** operation and paste it in a new tab of your web browser
+- **Question:** What is the name of the pet you retrieved?
+- **Question:** What if you change the numerical id to **2**, **3** or **4** in the mock URL?
+
+**To complete your understanding**, explain:
+
+- how the mock is generated: where do those pets come from?
+- what would be needed to add **Tigresse**, **Maki** and **Toufik** as valid responses to the **GET /pets/{id}** operation?
+- how the future customers of ACME can use this mock to develop their implementation ahead?

lab-instructions/content/overview/_index.md

@@ -0,0 +1,12 @@
++++
+title = "Overview"
+weight = 1
+chapter = true
+pre = "<b>1. </b>"
++++
+
+### Chapter 1
+
+# Overview
+
+Click the big red arrow on the right side of the screen to start with a **definition of the API Lifecyle**! 

lab-instructions/content/overview/api-lifecycle.md

@@ -0,0 +1,69 @@
+---
+title: "The API Lifecycle"
+weight: 1
+---
+
+*This post was originally published on the [Red Hat Developer Blog](https://developers.redhat.com/blog/2019/02/25/full-api-lifecycle-management-a-primer/)*.
+
+As shown below, the API lifecycle is two-fold. The leftmost cycle covers the producer activities, while the rightmost cycle covers the consumer activities.
+
+![Steps of the API Lifecycle](steps.png)
+
+## What are the goals for your APIs?
+
+Any API program has to start with a **Strategy** phase where you will have to define the goals you want to achieve with your APIs. It also specifies which markets you need to address, which resources you have at your disposal, the time frame you have in which to achieve your goals, and so on. This is a critical step to help you put effort where it matters the most.
+
+The **Design** phase will ensure your organization uses a contract-first approach. This phase entails gathering feedback early, breaking the dependencies between projects, and reducing risks. Also, a contract-first approach is known to reduce the time to market.
+
+In the **Design** phase, you design the contract of your API and share it with your future consumers. The outcome of the **Design** phase is an API contract that describes the messages that can be exchanged with your APIs.
+
+## Specify your APIs
+
+In the **Mock** phase, you will define meaningful payload examples of your APIs and try to refine your specifications with business expectations for common and edge cases. Those examples are then turned into a live mock that can be exposed to your first consumers. “Business expectations” entail everything that cannot be specified using a formal schema. An example could be that when querying items by status, all returned items must have the desired status. You could also think about mutually exclusive options or dependencies between fields: for example, if the field companyName is set, then the field accountType needs to be “enterprise.”
+
+In an acceptance test-driven development approach, you will have to define your test cases, based on examples, before implementing your APIs. This will help refine the business expectations about your APIs; share them between developers, testers, and business customers; and later ensure your APIs conform to those expectations.
+
+Here’s an example that will highlight the importance of the **Mock** and **Test** phases. If you are a retail company, you will have to return an error if someone under 21 tries to buy alcohol. That’s not something you can formally model in an API contract, but it will instead be reflected in your mocks and your tests.
+
+## Develop and Deploy your APIs
+
+Then, in the **Implement** phase, the actual API is **developed** using either an integration framework such as Red Hat Fuse or using the development language of your choice. Using an integration framework should be a key part of your APIs’ lifecycle to promote reuse, fast iterations, and value additions through orchestration. It also helps to modernize the existing parts of your information system. The usual agile development practices apply here.
+
+In the **Deploy** phase, you will make sure you have a Continuous Integration/Continuous Deployment (CI/CD) pipeline that automates the delivery of your APIs to the production environment. The CI/CD pipeline reuses the tests you defined earlier to ensure the APIs to be deployed do not violate your specifications. Those integration tests are automated and run automatically as part of the pipeline.
+
+The automated integration tests should also ensure the backward compatibility of your APIs. If a 1.2 version of an API is released, it must be backward compatible with any release of the 1.x branch (1.0, 1.1, and so on).
+
+The **Secure** phase is a reminder that security is a key step in the API lifecycle. Automated security testing, such as static analysis or vulnerability testing, should be part of your CD pipeline. Secure development practices, such as code reviews, a security development lifecycle, or OWASP Top 10 should also be part of your development lifecycle.
+
+In the **Manage** phase, after the APIs are deployed and secured, they need to be managed. This activity encompasses versioning, deprecation, and retirement. As a best practice, versioning should follow the semantic versioning scheme. This means when it is deployed, any new minor version of an API replaces the previous version. All consumers that were using the previous version are then using the latest version. When a breaking change occurs, a major version is released and deployed side by side with the previous one. Consumers can migrate from the previous version to the current one. They migrate at their own pace by adapting their code to the new version.
+
+This concludes the producer cycle of full API lifecycle management, and we can now speak about the consumer cycle.
+
+## Promote your APIs
+
+When your APIs are deployed in production and they are “live,” you enter the **Discover** phase. In this phase, you need to help your partners and other third parties discover your APIs. Just like your corporate website is the showroom for your products and offerings, an API developer portal is a showroom for your APIs. Make sure you put as much effort into this showroom as you do for your corporate website if you want to drive revenue through APIs!
+
+In the **Develop** phase, third parties will start discovering your APIs and developing applications based on your APIs. The user experience of those applications will depend on the quality of your APIs but also on the client applications. Make sure you are providing enough resources for developers to get the most out of your APIs. Those resources can be best practices, information on how to handle security and retries on errors, and so on.
+
+In the **Consume** phase, client applications will start consuming your APIs and you might want to have staged plans to match their growing consumption. To ensure a high-quality user experience, you might also want to set up an application validation process to reach your production APIs—if this is part of your API strategy, of course.
+
+## Refine your APIs
+
+After your first version has been released, you will need to prepare the next version and the one after that. This requires you to set up a kind of feedback loop to know what to improve next. This is the **Monitor** phase.
+
+To get accurate data in your feedback loop, you will have to monitor various aspects of your APIs. This ranges from developer engagement to API health, to API usage, and so on. The “Time to first Hello, World!” is a useful metric to track to know if your APIs are easy enough to be learned quickly by new developers.
+
+As your APIs mature, so does your business model. At some point, you might be interested in billing your consumers according to their usage of your APIs; if so, this is the **Monetize** phase. A desire to monetize is especially likely if you are targeting a myriad of small third parties to benefit from a mass effect. In that case, you definitely want to have monetization with billing and payment built in.
+
+## An API strategy to ensure the cycles repeat
+
+The cycles repeat, and this is at the center of both cycles. This is not by coincidence: an **API strategy** is the cornerstone of a successful API program. Knowing which goals you need to reach will help you to focus on what matters the most.
+
+Red Hat technologies and communities can help with full API lifecycle management. The diagram below shows tools for full API lifecycle management:
+
+![Tools for the API Lifecycle](tools.png)
+
+Communities such as Apicurio and Microcks will help you with the design, mock, and tests. A whole development offering such as Red Hat Fuse, Red Hat OpenShift Application Runtimes, or Red Hat CodeReady Workspaces can help you develop reliable API back ends. Red Hat Ansible Automation can help you with the Continuous Delivery of your APIs. Red Hat Single Sign-On can help secure your APIs, and Red Hat 3scale API Management handles the rest of the API lifecycle. Last but not least, Red Hat can help you define your API strategy through a service offering: the API Model Canvas.
+
+Red Hat OpenShift Container Platform is a the core of this lifecycle, since it is the component that brings agility and makes this approach flow more easily.
+

lab-instructions/content/overview/environment.md

@@ -0,0 +1,8 @@
+---
+title: "The workshop environment"
+weight: 3
+---
+
+During this workshop, you will go through the Mocking and Testing of a REST API.
+
+The workshop is run in the {{< param company >}}'s OpenShift environment.

lab-instructions/content/overview/platform.md

@@ -0,0 +1,15 @@
+---
+title: "Exercise: Discover the platform"
+weight: 4
+---
+
+In this exercise, we will have a look at the platform hosting this workshop and the different tools we will use throughout the whole API Lifecycle.
+
+- First, open the [Apicurio Studio]({{< param apicurio_studio_url >}})
+- Login with your {{< param company >}} username
+- Click **Settings** > **Linked accounts**
+- Click the **Link** button, on the right side of the **GitHub** logo.
+- Complete the process
+- Then, open the [Microcks UI]({{< param microcks_url >}})
+
+Raise your hand if you have trouble to complete this step! An instructor will come help you promptly.

lab-instructions/content/overview/use-case.md

@@ -0,0 +1,12 @@
+---
+title: "The Use Case"
+weight: 2
+---
+
+Before we dig in, let’s examine a use case that will help illustrate this approach through an example: the Petstore API. ACME produces, stores, and distributes pets to its beloved customers, and the whole process is managed in-house.
+
+The increasing competition and the growing demand of the customer base are forcing ACME to rethink its distribution model. Namely, the distribution will be left to independent resellers that could sell pets locally, online or on-site. The main challenge is how to open up the information system so that independent resellers can discover the pets, check inventory, and so on. This can be done through the exposition of an API, of course.
+
+Let's help ACME to succeed in the API world!
+
+Source: [An API Journey: From Idea to Deployment the Agile Way–Part I, from Laurent Broudoux](https://developers.redhat.com/blog/2018/04/11/api-journey-idea-deployment-agile-part1/)

lab-instructions/content/publish/_index.md

@@ -0,0 +1,12 @@
++++
+title = "Publish"
+weight = 6
+chapter = true
+pre = "<b>6. </b>"
++++
+
+### Chapter 6
+
+# Publish
+
+Because ACME adheres to the Infrastructure-as-Code and API-Management-as-Code principles, everything needs to be versioned in a GIT repository and automated.

lab-instructions/content/publish/exercise-cicd.md

@@ -0,0 +1,27 @@
+---
+title: "Exercise: CI/CD"
+weight: 2
+---
+
+## Include the Microcks tests in your CI/CD pipeline
+
+Because ACME adheres to the Infrastructure-as-Code and API-Management-as-Code principles, everything needs to be versioned in a GIT repository and deployed automatically without human intervention.
+ACME would like to trigger the Microcks tests from their CI/CD pipeline, based on GitHub Actions or Tekton.
+
+In this exercise, you will trigger a Microcks test from the CLI (we can imagine that someone at ACME would add this CLI to the CI/CD pipeline...).
+
+- Have a look at the [microcks-cli](https://github.com/microcks/microcks-cli) project
+- Run the following command in a shell:
+
+```sh
+docker run -it microcks/microcks-cli:latest microcks-cli test 'Petstore API <your_login>:1.2.0' {{< param petstore_api_fixed >}} OPEN_API_SCHEMA --microcksURL={{< param microcks_url >}}/api/ --keycloakClientId={{< param microcks_client_id >}} --keycloakClientSecret={{< param microcks_client_secret >}} --waitFor=60sec
+```
+
+If everything went fine, you should see something similar to:
+
+```raw
+MicrocksClient got status for test "5dc2f6a7d7e470000114d1d4" - success: false, inProgress: true
+MicrocksTester waiting for 2 seconds before checking again or exiting.
+MicrocksClient got status for test "5dc2f6a7d7e470000114d1d4" - success: true, inProgress: false
+```
+

lab-instructions/content/publish/exercise-git.md

@@ -0,0 +1,22 @@
+---
+title: "Exercise: GIT"
+weight: 1
+---
+
+## Publish your API Contract in a GIT repository
+
+Because ACME adheres to the Infrastructure-as-Code and API-Management-as-Code principles, everything needs to be versioned in a GIT repository.
+In this exercise, you will create a GIT repository and publish your API contract.
+
+- Go to your [favourite GIT provider]({{< param github_url >}})
+- Create a repository named `petstore-api`
+- **Hint:** You can initialize it with a README and a license file when proposed by your GIT provider
+- Open the [APICurio Studio]({{< param apicurio_studio_url >}}/apis)
+- Open your **Petstore** API
+- Click the **three dots button** and select **Publish...**
+- Click your favourite GIT provider's icon
+- Select your login in the **Organization** dropdown list
+- Select `petstore-api` in the **Repository** dropdown list
+- In the **Resource** field, type `openapi.yaml`
+- Fill-in the commit message with something relevant
+- Click **Publish API**

lab-instructions/content/test/_index.md

@@ -0,0 +1,14 @@
++++
+title = "Test"
+weight = 5
+chapter = true
+pre = "<b>5. </b>"
++++
+
+### Chapter 5
+
+# Test
+
+In an acceptance test-driven development approach, you will have to define your test cases, based on examples, before implementing your APIs. This will help refine the business expectations about your APIs; share them between developers, testers, and business customers; and later ensure your APIs conform to those expectations.
+
+Here’s an example that will highlight the importance of the **Mock** and **Test** phases. If you are a retail company, you will have to return an error if someone under 21 tries to buy alcohol. That’s not something you can formally model in an API contract, but it will instead be reflected in your mocks and your tests.

lab-instructions/content/test/exercise1.md

@@ -0,0 +1,32 @@
+---
+title: "Exercise 1"
+weight: 1
+---
+
+## Run an integration test suite for the ACME Petstore API!
+
+The ACME Petstore has implemented the ACME Petstore API and is about to deploy it into production.
+But ACME is unsure about the conformity of its implementation in regards to the API contract.
+**Can you help them check if their API matches the API contract?**
+
+The ACME Petstore API implementation has been deployed here:
+
+```raw
+{{< param petstore_api >}}
+```
+
+- Open the [APICurio Studio]({{< param apicurio_studio_url >}}/apis)
+- Open your **Petstore** API
+- Scroll down and click **View in Microcks**
+- In the **Microcks UI**, click **+ New Test**
+- Fill-in the **Test Endpoint** with `{{< param petstore_api >}}`
+- Change the **Runner** to **OPEN API SCHEMA**
+- Click **+ Launch test!**
+- Wait for the test to complete and click **Full results**
+- **Question:** How many tests passed? How many failed?
+- **Question:** Can you explain why those tests failed?
+
+**To complete your understanding**, explain:
+
+- which changes would be required in the API contract?
+- which changes would be required in the API implementation?

lab-instructions/content/test/exercise2.md

@@ -0,0 +1,40 @@
+---
+title: "Exercise 2"
+weight: 2
+---
+
+## Update the API Contract to extend the test coverage
+
+In the previous exercise, ACME discovered its API implementation is not conform to the API contract, this will require some more refinement from the development team.
+But ACME also discovered **one missing case** that prevent Microcks from properly asserting the conformity of the API implementation.
+
+In this exercise, you will update the API contract to add examples to the **DELETE /pets/{id}** method.
+
+- Open the [APICurio Studio]({{< param apicurio_studio_url >}}/apis)
+- Open your **Petstore** API
+- Click **Edit API**
+- Start by changing the version number of your API to **1.2.0**
+- In the left pane, open the **/pets/{id}** path
+- Click **DELETE**
+- Scroll down to the **Path parameters** section
+- Click **Override**
+- Add an example **that you will name "dummy"**
+- Set this example's value to `0`
+- Scroll down to the **Responses** section
+- Add an example **that you will name "dummy"**
+- Fill-in this example with:
+
+```json
+{"id":0,"name":"Dummy","tag":"dumb"}
+```
+
+- In the breadcrumb, click your **Petstore** API
+- Scroll down and click **Update Mock in Microcks** > **Mock API** > **OK**
+- Click **View in Microcks**
+- Unfold the **DELETE /pets/{id}** operation
+- **Question:** can you see the examples you defined in Apicurio?
+
+**To complete your understanding**, explain:
+
+- Why we defined an example named "dummy" instead of a proper one such as "zaza"?
+- What would be the appropriate setup in a real life scenario?

lab-instructions/content/test/exercise3.md

@@ -0,0 +1,25 @@
+---
+title: "Exercise 3"
+weight: 3
+---
+
+## Re-run the test suite
+
+In the previous exercise, you updated the API contract to add examples to the **DELETE /pets/{id}** method so that Microcks can assert the whole Petstore API.
+In the meantime, the development team fixed the **POST /pets** operation to return **200 OK** as required by the API Contract.
+
+The updated ACME Petstore API implementation has been deployed here:
+
+```raw
+{{< param petstore_api_fixed >}}
+```
+
+- Open the [APICurio Studio]({{< param apicurio_studio_url >}}/apis)
+- Open your **Petstore** API
+- Scroll down and click **View in Microcks**
+- In the **Microcks UI**, click **+ New Test**
+- Fill-in the **Test Endpoint** with `{{< param petstore_api_fixed >}}`
+- Change the **Runner** to **OPEN API SCHEMA**
+- Click **+ Launch test!**
+- Wait for the test to complete and click **Full results**
+- **Question:** Did all the tests passed?

lab-instructions/layouts/partials/logo.html

@@ -0,0 +1 @@
+<a href="/"><img src="/images/logo.png" /></a>

lab-instructions/themes/learn

@@ -0,0 +1 @@
+Subproject commit 51dbdcf4aaef01d02e78a6ea76b2a6fde5842b55