Update ref-other-scenarios.md

* develop:
  Update send-http-requests.md

articles/testing/pass-data-steps.md

@@ -1 +1,75 @@
+# Pass Data Between Steps 
 
+Most scenarios will involve more than one step, and oftentimes you will need to share data between steps.
+
+For example, imagine a simple scenario that tests the CRUD operations on a "todos" model. It might involve 5 steps:
+
+1. CREATE /todos
+2. GET /todos/{todoId}
+3. PUT /todos/{todoId}
+4. DELETE /todos/{todoId}
+5. GET /todos/{todoId} (to make sure 404 not found)
+
+In order for this to work, steps 2-5 need to be able to access the `id` of the newly created todo in step 1. To do this, we'll save the new `id` property in step 1 to the $.ctx object.
+
+### The $.ctx object
+
+The $.ctx object makes it easy to store temporary data for use during the course of a single scenario run. By default, the $.ctx object will be empty at the start of every run. Use it to share data between steps.
+
+### Using the $.ctx object
+
+To use a ctx variable in your scenario, simply use the {$.ctx.variableName} syntax. For example, if your ctx variable is called `todoId`, and you want to use it in your step's URL, you would do something like this:
+
+`/todos/{$.ctx.todoId}`
+
+When the step is run, `{$.ctx.todoId}` will be replaced by whatever $.ctx.todoId has been set to in a previous step.
+
+You can use variables anywhere in your step, including url, auth, headers, request body, assertions, captures, and scripting.
+
+To use environments in a before script, after script, or step with type script:
+
+```js
+// would print the postId
+console.log($.ctx.get('todoId');
+```
+
+In the screenshot below, we are using a `todoId` ctx variable that is set in a previous step. It is helping us create the URL, and is also used in a test assertion to make sure that the API request responds with the exact id we are requesting.
+
+![](../../assets/images/$.ctx.todoId-Assertion.png)
+
+### Setting ctx variables
+
+#### With Captures
+
+Save values from your step to your ctx object, for use in subsequent steps.
+
+To accomplish this, open up the Captures tab of one of your steps and select $.ctx on the lefthand side of the assignment. In the image below we are saving the todoId property of the Create Todo response back to a variable on our ctx called `todoId`. We will use this variable in subsequent steps.
+
+![](../../assets/images/$.ctx.todoId-Capture.png)
+
+#### With Scripting
+
+When you need more complicated conditional logic or processing, scripting is the way to go. Scripts are plain javascript, and give you access to the $.ctx object. You can achieve the same results as the capture screenshot above as seen in the screenshot below.
+
+![](../../assets/images/$.ctx.todoId-Scripting.png)
+
+### When to use ctx variables
+
+You can think of ctx variables as a temporary state in your scenario. In general, we recommend using them for values that are created during the course of a single scenario that need to be shared with subsequent steps. This includes things like ids, usernames, and randomly generated tokens.
+
+<!-- theme: warning -->
+> We do **NOT** recommend using ctx variables for more permanent values that need to persist across scenario runs. For this persisted value use case, we recommend using the $$.env object, which is explained in detail [here](variables-environment.md).
+
+### Debugging ctx variables
+
+$.ctx variables can be manually set when running a step. This is useful if you are trying to debug a single step in the middle of a scenario that relies on a ctx value set in a previous step. Instead of running the entire scenario to generate the needed ctx value, you can set it in the UI manually. In the screenshot below, we can set the todoId ctx variable before running the step to debug what would happen with a particular todoId value.
+
+![](../../assets/images/$.ctx.todoId-Manual.png)
+
+---
+
+**Related**
+
+* [Variables Overview](variables-overview.md)
+* [Context Variables](variables-context.md)
+* [Variables Environment](variables-environment.md)

articles/testing/ref-other-scenarios.md

@@ -1 +1,29 @@
+# Scenario References
 
+References are a special type of step that allow you to include other scenarios in your scenario. This is a very powerful concept that can dramatically reduce the duplication in your scenarios.
+
+To reference another scenario, add a step to an existing scenario and change it's type from "HTTP/Script" to "REF". This will expose a dropdown that lists all of the scenarios in your collection. Select a value from the dropdown to create the ref to that scenario.
+
+In the screenshot below, [Todo: Utility CRUD](https://next.stoplight.io/stoplight/hub/blob/master/tests.scenarios.yml?edit=%23%2Fscenarios%2Ftodo-utility) and [User: Utility CRUD](https://next.stoplight.io/stoplight/hub/blob/master/tests.scenarios.yml?edit=%23%2Fscenarios%2Fuser-utility) scenario have one step that refrences [Entity CRUD](https://next.stoplight.io/stoplight/hub/blob/master/tests.scenarios.yml?edit=%23%2Futilities%2Fcrud) from Utilities. Entity CRUD does all the heavy lifting: it CREATES, GETS, UPDATES, DELETES, and repeats GETS (To verify entity was deleted) an entity.
+
+$.ctx values saved in ref steps **ARE** available in subsequent steps. The ref step in the screenshot below saves a $.ctx.accessToken property (not displayed), that the "Create Org" step then uses.
+
+![](https://s3.amazonaws.com/cdn.stoplight.io/help-portal/scenarios/create+org+%2B+user+with+ref.png)
+_need to update image_
+
+### Viewing Reference Output
+
+When a reference is run as part of a scenario, its output will expand so that you can view the results of each step. In the screenshot below, we are looking at the results of the `Todo: Utility CRUD` scenario pictured above.
+
+Tests and assertions made in a referenced scenario **will** contribute to the overall pass/fail count of the calling scenario.
+
+![](https://s3.amazonaws.com/cdn.stoplight.io/help-portal/scenarios/view+ref+output.png)
+_need to update image_
+
+---
+
+**Related**
+
+* [Variables Overview](variables-overview.md)
+* [Context Variables](variables-context.md)
+* [Variables Environment](variables-environment.md)

articles/testing/scenarios-introduction.md

@@ -1,17 +1,26 @@
-Stoplight Scenarios is a powerful (but accessible!) tool that takes the pain out of API testing. It is a standalone product, available on [the web](https://scenarios.stoplight.io), and as a [desktop app](https://download-next.stoplight.io).
+Stoplight Scenarios is a powerful (but accessible!) tool that takes the pain out of API testing. It's available on [the web](https://next.stoplight.io) and as a [desktop app](https://download-next.stoplight.io).
 
 We generally recommend the desktop app when possible. It works with local servers, behind firewalls, and exchanges information with tools on your computer like Git or your favorite IDE. You can switch seamlessly between the desktop app and the web app.
 
 We engineered Scenarios from the ground up to be:
 
-- **Powerful** Easily assert, capture, transform, and validate your API Spec (Swagger) against your actual API. And if that isn’t enough, Prism has a powerful javascript runtime.
+* **Powerful** Easily assert, capture, transform, and validate your API Spec (OpenAPI) against your actual API. And if that isn’t enough, Prism has a powerful javascript runtime.
 
-- **Portable** Scenarios are described in plain JSON with a well thought out, robust specification. Use our visual editor to quickly generate and manage this JSON. They can be run from our visual tooling, or completely outside of Stoplight, on your own machines or on your continuous integration server.
+* **Portable** Scenarios are described in plain JSON with a well thought out, robust specification. Use our visual editor to quickly generate and manage this JSON. Scenarios can be run from our visual tooling, or completely outside of Stoplight, on your own machines, or on your continuous integration server.
 
-- **Flexible** Your APIs, your tests, your way. Scenarios only test what you want them to. They have no opinion about your architecture (Monolithic vs Microservices), company structure (in house vs distributed), development lifecycle (production vs TDD), and your environment (development vs staging vs production).
+* **Flexible** Your APIs, your tests, your way. Scenarios only test what you want them to. They have no opinion about your architecture (Monolithic vs Microservices), company structure (in house vs distributed), development lifecycle (production vs TDD), and your environment (development vs staging vs production).
 
-- **Fast** Time can’t be slowed down, and we can’t give it back to you. Creating tests should be quick, and waiting for you tests to run shouldn’t feel like watching water boil. Scenarios are run concurrently for maximum speed - run hundreds of API requests and test assertions in seconds.
+* **Fast** Time can’t be slowed down, and we can’t give it back to you. Creating tests should be quick, and waiting for you tests to run shouldn’t feel like watching water boil. Scenarios are run concurrently for maximum speed - run hundreds of API requests and test assertions in seconds.
 
 ### Editor UI Overview
 
-![](https://cdn.stoplight.io/help-portal/scenarios/scenario-editor-callout.png)
+![](../../assets/images/scenarios-editor-overview.png)
+
+---
+
+**Related**
+
+* [Prism Introduction](../prism/overview.md)
+* [Leveraging Open API](levergage-openapi.md)
+* [Continuous Integration](continuous-integration.md)
+* [Run Scenarios In Stoplight](run-test-stoplight.md)