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
@@ -26,7 +26,7 @@ shared responses.
|
||||
|
||||
## Using the Editor
|
||||
|
||||
<!-- FIXME: Insert GIF of using the editor, creating objects, setting their type, etc -->
|
||||

|
||||
|
||||
We created the CRUD builder editor to make data structure creation as simple as
|
||||
possible. You can find the CRUD builder editor under the **Editor** tab under
|
||||
@@ -87,7 +87,7 @@ If you have a pre-existing JSON document that you would like to convert to a
|
||||
Stoplight data structure, the **Generate from JSON** button available towards
|
||||
the top of the CRUD editor allows you to do just that.
|
||||
|
||||
<!-- FIXME: Insert GIF of the generate from json feature -->
|
||||

|
||||
|
||||
To start:
|
||||
|
||||
@@ -107,7 +107,7 @@ bodies, and shared responses.
|
||||
|
||||
## Editing the Raw JSON Schema
|
||||
|
||||
<!-- FIXME: Insert GIF of clicking the 'raw schema' button and editing the json -->
|
||||

|
||||
|
||||
While not for the faint hearted, you can also edit the raw JSON schema directly
|
||||
if you are familiar with the format, or have a pre-existing JSON schema
|
||||
|
||||
@@ -42,6 +42,10 @@ different types of vehicles. To begin working on the API, you will need a base
|
||||
"car" model with a few attributes that are common across all vehicles. This
|
||||
might look similar to:
|
||||
|
||||

|
||||
|
||||
The JSON schema will be:
|
||||
|
||||
```javascript
|
||||
// the car base type
|
||||
{
|
||||
@@ -67,12 +71,14 @@ might look similar to:
|
||||
}
|
||||
```
|
||||
|
||||
<!--FIXME Insert image of creating model from UI -->
|
||||
|
||||
Now that we have a base type model, we now need a derived type that extends the
|
||||
base type. Since we're dealing with cars, let's create a model that defines a
|
||||
SUV type (or a Sport Utility Vehicle):
|
||||
|
||||

|
||||
|
||||
The JSON schema will be:
|
||||
|
||||
```javascript
|
||||
// the SUV model
|
||||
{
|
||||
@@ -99,8 +105,6 @@ SUV type (or a Sport Utility Vehicle):
|
||||
}
|
||||
```
|
||||
|
||||
<!--FIXME Insert image of creating derived model in UI -->
|
||||
|
||||
As shown above, by wrapping our SUV model inside of an `allOf` block, we are
|
||||
able to include all of the properties that are included in the car base model
|
||||
above.
|
||||
@@ -108,6 +112,10 @@ above.
|
||||
When fully de-referenced (the car reference is replaced with the car
|
||||
properties), the derived SUV model will have the following JSON properties:
|
||||
|
||||

|
||||
|
||||
The JSON schema will be:
|
||||
|
||||
```javascript
|
||||
{
|
||||
"type": "object",
|
||||
@@ -139,9 +147,12 @@ properties), the derived SUV model will have the following JSON properties:
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
**Related Articles**
|
||||
- [JSON Introduction](/modeling/json-best-practices/introduction)
|
||||
- [Adding Validations](/modeling/json-best-practices/adding-validations)
|
||||
- [Reducing Duplication with $refs](/modeling/json-best-practices/reducing-duplication-with-refs)
|
||||
- [Generating Schemas](/modeling/json-best-practices/generating-schemas)
|
||||
|
||||
**Related Articles**
|
||||
|
||||
* [JSON Introduction](/modeling/json-best-practices/introduction)
|
||||
* [Adding Validations](/modeling/json-best-practices/adding-validations)
|
||||
* [Reducing Duplication with $refs](/modeling/json-best-practices/reducing-duplication-with-refs)
|
||||
* [Generating Schemas](/modeling/json-best-practices/generating-schemas)
|
||||
|
||||
@@ -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