review feedback

README.md

@@ -24,7 +24,15 @@ This workshop should take from 1 to 2 hours, depending on how deep you want to g
 - [step 12: **broker webhooks**](https://github.com/pact-foundation/pact-workshop-js/tree/step12#step-12---using-webhooks): Trigger provider workflows when contracts change, via webhooks
 - [step 13: **pactflow broker**](https://github.com/pact-foundation/pact-workshop-js/tree/step13#step-13---using-a-pactflow-broker): Implement a managed pactflow workflow for integration with CI/CD
 
-_NOTE: Each step is tied to, and must be run within, a git branch, allowing you to progress through each stage incrementally. For example, to move to step 2 run the following: `git checkout step2`_
+_NOTE: Each step is tied to, and must be run within, a git branch, allowing you to progress through each stage incrementally._
+
+_EG: Move to step 2:_
+
+_`git checkout step2`_
+
+_`npm install`_
+
+<hr/>
 
 ## Learning objectives
 
@@ -103,10 +111,18 @@ We can run the client with `npm start --prefix consumer` - it should fail with t
 
 ## Step 2 - Client Tested but integration fails
 
+_NOTE: Move to step 2:_
+
+_`git checkout step2`_
+
+_`npm install`_
+
+<hr/>
+
 Now lets create a basic test for our API client. We're going to check 2 things:
 
 1. That our client code hits the expected endpoint
-1. That the response is marshalled into an object that is usable, with the correct ID
+2. That the response is marshalled into an object that is usable, with the correct ID
 
 You can see the client interface test we created in `consumer/src/api.spec.js`:
 
@@ -220,6 +236,14 @@ We need to have a conversation about what the endpoint should be, but first...
 
 ## Step 3 - Pact to the rescue
 
+_NOTE: Move to step 3:_
+
+_`git checkout step3`_
+
+_`npm install`_
+
+<hr/>
+
 Unit tests are written and executed in isolation of any other services. When we write tests for code that talk to other services, they are built on trust that the contracts are upheld. There is no way to validate that the consumer and provider can communicate correctly.
 
 > An integration contract test is a test at the boundary of an external service verifying that it meets the contract expected by a consuming service — [Martin Fowler](https://martinfowler.com/bliki/IntegrationContractTest.html)
@@ -367,6 +391,14 @@ A pact file should have been generated in *consumer/pacts/FrontendWebsite-Produc
 
 ## Step 4 - Verify the provider
 
+_NOTE: Move to step 4:_
+
+_`git checkout step4`_
+
+_`npm install`_
+
+<hr/>
+
 We need to make the pact file (the contract) that was produced from the consumer test available to the Provider module. This will help us verify that the provider can meet the requirements as set out in the contract. For now, we'll hard code the path to where it is saved in the consumer test, in step 11 we investigate a better way of doing this.
 
 Now let's make a start on writing Pact tests to validate the consumer contract:
@@ -407,7 +439,7 @@ To simplify running the tests, add this to `provider/package.json`:
 
 ```javascript
 // add it under scripts
-"test:pact": "npx jest --testTimeout=30000 --testMatch \"**/*.pact.test.js\""
+"test:pact": "jest --testTimeout=30000 --testMatch \"**/*.pact.test.js\""
 ```
 
 We now need to validate the pact generated by the consumer is valid, by executing it against the running service provider, which should fail:
@@ -453,6 +485,14 @@ Move on to [step 5](https://github.com/pact-foundation/pact-workshop-js/tree/ste
 
 ## Step 5 - Back to the client we go
 
+_NOTE: Move to step 5:_
+
+_`git checkout step5`_
+
+_`npm install`_
+
+<hr/>
+
 We now need to update the consumer client and tests to hit the correct product path.
 
 First, we need to update the GET route for the client:
@@ -539,6 +579,14 @@ Move on to [step 6](https://github.com/pact-foundation/pact-workshop-js/tree/ste
 
 ## Step 6 - Consumer updates contract for missing products
 
+_NOTE: Move to step 6:_
+
+_`git checkout step6`_
+
+_`npm install`_
+
+<hr/>
+
 We're now going to add 2 more scenarios for the contract
 
 - What happens when we make a call for a product that doesn't exist? We assume we'll get a `404`.
@@ -671,7 +719,7 @@ Failures:
            expected 404 but was 200
 ```
 
-We expected this failure, because the product we are requesting does in fact exist! What we want to test for, is what happens if there is a different *state* on the Provider. This is what is referred to as "Provider states", and how Pact gets around test ordering and related issues.
+We expected this failure, because the product we are requesing does in fact exist! What we want to test for, is what happens if there is a different *state* on the Provider. This is what is referred to as "Provider states", and how Pact gets around test ordering and related issues.
 
 We could resolve this by updating our consumer test to use a known non-existent product, but it's worth understanding how Provider states work more generally.