Image updates (#172)
* Add new gifs for crud builder * Add links * Update object-inheritance * Update variables context file with gif and link. Add object inheritance images. * Update variable environments article.
This commit is contained in:
committed by
Robert Wallach
parent
f0855e2c3a
commit
d39835fb09
@@ -1,8 +1,6 @@
|
||||
# Using Context Variables
|
||||
|
||||
<!--(FIXME - SHOW WRITING VARIABLE TO CONTEXT IN STEP)-->
|
||||
|
||||
Context variables allow you to dynamically store and share data between steps in a scenario. Contrary to environment variables, context variables are _not_ saved once a test has completed. Therefore, context variables are only suitable for temporary data.
|
||||
Context variables allow you to dynamically store and share data between steps in a scenario. Contrary to environment variables, context variables are _not_ saved once a test has completed. Therefore, context variables are only suitable for temporary data.
|
||||
|
||||
Context variables are scoped to the scenario, _not_ the collection. This means that two scenarios can both read/write the same context variable `myVar`, and not conflict with each other. Environment variables, on the other hand, are shared amongst all scenarios, and are scoped to the collection.
|
||||
|
||||
@@ -12,9 +10,9 @@ At the start of a test run, the context object is empty. Good examples of data t
|
||||
|
||||
Context variables make it possible to chain related steps together. For example, say we have the following set of actions to perform:
|
||||
|
||||
1. Create User, `POST /users`. Returns a new user object, with an `id` property.
|
||||
2. Get User, `GET /users/{$.ctx.userId}`.
|
||||
3. Delete User, `DELETE /users/{$.ctx.userId}`.
|
||||
1. Create User, `POST /users`. Returns a new user object, with an `id` property.
|
||||
2. Get User, `GET /users/{$.ctx.userId}`.
|
||||
3. Delete User, `DELETE /users/{$.ctx.userId}`.
|
||||
|
||||
Somehow we need to use the `id` property for the user created in step #1 to build the request in steps #2 and #3. This is a great case for context variables, since the data is temporary (the new user's id changes every test run, and is only needed in this single scenario).
|
||||
|
||||
@@ -24,16 +22,14 @@ To accomplish this, we would capture/set the `$.ctx.userId` property to `output.
|
||||
|
||||
### With Captures
|
||||
|
||||
<!--(FIXME - SHOW USING THE CAPTURE MENU IN A SCENARIO STEP)-->
|
||||
|
||||
The capture UI in the step editor makes it easy to set `$.ctx` values. You can use values from the step output or input, including headers, response bodies, etc.
|
||||
|
||||

|
||||
|
||||
> Multiple captures can be applied to the same step, to set multiple `$.ctx` values.
|
||||
|
||||
### With Scripting
|
||||
|
||||
<!--(FIXME - SHOW SCREENSHOT OF SCRIPT IN STEP)-->
|
||||
|
||||
Scripting allows you to use more complicated logic in a scenario step. Scripts
|
||||
are executed either before or after a step request finishes. Scripts are plain
|
||||
Javascript and give you direct access to the scenario context through the global
|
||||
@@ -48,7 +44,7 @@ $.ctx.set('userId', output.body.get('id'));
|
||||
|
||||
Where the `$.ctx.set(x, y)` function adds the data referenced in the second
|
||||
argument (`y`) to the context under the string value of the first argument
|
||||
(`x`).
|
||||
(`x`).
|
||||
|
||||
Here is another example that just sets `myVariable` to the hardcoded value `123`:
|
||||
|
||||
@@ -58,8 +54,6 @@ $.ctx.set('myVariable', 123);
|
||||
|
||||
## Using Context Variables
|
||||
|
||||
<!--(FIXME - SHOW USING A CONTEXT VARIABLE IN A SCENARIO STEP)-->
|
||||
|
||||
To use a context variable in a scenario, use the following syntax:
|
||||
|
||||
```
|
||||
@@ -91,10 +85,8 @@ Where the braces (`{}`) are absent, and we are using the `get()` method for
|
||||
retrieving the context variable under the `myVariable` key.
|
||||
|
||||
---
|
||||
|
||||
**Related Articles**
|
||||
- [Using Variables Overview](/testing/using-variables/overview)
|
||||
- [$$.env (Environment)](/testing/using-variables/environment)
|
||||
|
||||
|
||||
|
||||
|
||||
* [Using Variables Overview](/testing/using-variables/overview)
|
||||
* [$$.env (Environment)](/testing/using-variables/environment)
|
||||
|
||||
@@ -1,15 +1,15 @@
|
||||
# Using Environment Variables
|
||||
|
||||
<!--(FIXME - SHOW CLICKING THROUGH ENVIRONMENTS IN UI)-->
|
||||
|
||||
> If you have not already done so, we recommend reviewing the
|
||||
[Environments](/platform/editor-basics/environments) article before continuing.
|
||||
> [Environments](/platform/editor-basics/environments) article before continuing.
|
||||
|
||||
Environment variables in Stoplight allow you to dynamically retrieve information
|
||||
in a scenario from the active environment. This makes it possible to
|
||||
switch between different environments with ease, having variables automatically
|
||||
populate based on the current environment.
|
||||
|
||||

|
||||
|
||||
## Setting Environment Variables
|
||||
|
||||
### With the Editor Configuration
|
||||
@@ -23,8 +23,8 @@ Captures make it easy to "capture" values from your step request or result, and
|
||||
Say you have a scenario step that sends an HTTP request to authenticate a new user. The response from that request includes an apiKey that you want to use for other requests. You can easily save that apiKey to an environment variable, for later re-use, by adding a capture in the form `$$.env.apiKey = output.body.apiKey`. After running the step, check your current environment variables and note the newly added apiKey!
|
||||
|
||||
> Environment variables set via captures are only added to the user's private
|
||||
variables, and are not sent to Stoplight. See the [Environment
|
||||
section](/platform/editor-basics/environments) for more information.
|
||||
> variables, and are not sent to Stoplight. See the [Environment
|
||||
> section](/platform/editor-basics/environments) for more information.
|
||||
|
||||
### With Scripting
|
||||
|
||||
@@ -45,13 +45,11 @@ argument (`y`) to the environment under the string value of the first argument
|
||||
(`x`).
|
||||
|
||||
> Environment variables set via script are only added to the user's private
|
||||
variables, and are not sent to Stoplight. See the [Environment
|
||||
section](/platform/editor-basics/environments) for more information.
|
||||
> variables, and are not sent to Stoplight. See the [Environment
|
||||
> section](/platform/editor-basics/environments) for more information.
|
||||
|
||||
## Using Environment Variables
|
||||
|
||||
<!--(FIXME - SHOW USING A VARIABLE IN A SCENARIO STEP)-->
|
||||
|
||||
Use an environment variable in a scenario with the following syntax:
|
||||
|
||||
```
|
||||
@@ -83,10 +81,11 @@ $$.env.get('myVariable');
|
||||
Where the braces (`{}`) are absent, and we are using the `get()` method for
|
||||
retrieving the environment variable under the `myVariable` key.
|
||||
|
||||
***
|
||||
**Related Articles**
|
||||
- [Editor Configuration](/platform/editor-basics/editor-configuration)
|
||||
- [Environments](/platform/editor-basics/environments)
|
||||
- [Using Variables Overview](/testing/using-variables/overview)
|
||||
- [$.ctx(Context)](/testing/using-variables/context)
|
||||
---
|
||||
|
||||
**Related Articles**
|
||||
|
||||
* [Editor Configuration](/platform/editor-basics/editor-configuration)
|
||||
* [Environments](/platform/editor-basics/environments)
|
||||
* [Using Variables Overview](/testing/using-variables/overview)
|
||||
* [$.ctx(Context)](/testing/using-variables/context)
|
||||
|
||||
Reference in New Issue
Block a user