Skip to content
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 16 additions & 16 deletions docs/getting-started/testing.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ icon: 'vial'
title: 'Testing & Validation'
---

Testing is critical process when building and maintaining an authorization system. This page explains how to ensure the new authorization model and related authorization data works as expected in Permify.
Testing is a critical process when building and maintaining an authorization system. This page explains how to ensure the new authorization model and related authorization data works as expected in Permify.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Testing is a critical process when building and maintaining an authorization system. This page explains how to ensure the new authorization model and related authorization data works as expected in Permify.
Testing is a critical process when building and maintaining an authorization system. This page explains how to ensure your authorization model and data works as expected in Permify.

[suggestion]: reduce duplication of 'authorization' in this paragraph. 3 times is probably too many in such a small paragraph!


Assuming that you're familiar with creating an authorization model and forming relation tuples in Permify. If not, we're strongly advising you to examine them before testing.

Expand Down Expand Up @@ -40,10 +40,10 @@ If you don't know how to create Github action workflow and add a action to it, y

## Schema Validation File

Below you can examine an example schema validation yaml file. It consists 3 parts;
- `schema` which is the authorization model you want to test,
- `relationships` sample data to test your model,
- `scenarios` to test access check queries within created scenarios.
Below, you can examine an example schema validation yaml file. It consists 3 parts;
- `schema` which is the authorization model you want to test
- `relationships` which is the sample data to test your model
- `scenarios` which is the way to actually test access check queries within created scenarios
Comment on lines +44 to +46

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- `schema` which is the authorization model you want to test
- `relationships` which is the sample data to test your model
- `scenarios` which is the way to actually test access check queries within created scenarios
- `schema`: the authorization model you want to test
- `relationships`: the sample data to test your model
- `scenarios`: the way to actually test access check queries within created scenarios

[suggestion]: why use more word when few word do trick?


### Defining the Schema:

Expand Down Expand Up @@ -149,17 +149,17 @@ scenarios:
edit : ["58"]
```

Assuming that you're well-familiar with the `schema` and `relationships` sections of the above YAML file. If not, please see the previous sections to learn how to create an authorization model (schema) and generate data (relationships) according to it.
You should be familiar with the `schema` and `relationships` sections of the above YAML file. If not, please see the previous sections to learn how to [create an authorization model (the schema)](/getting-started/modeling) and [generate data (relationships)](/getting-started/sync-data) according to a schema.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
You should be familiar with the `schema` and `relationships` sections of the above YAML file. If not, please see the previous sections to learn how to [create an authorization model (the schema)](/getting-started/modeling) and [generate data (relationships)](/getting-started/sync-data) according to a schema.
For more information about the `schema` and `relationships` sections of the above YAML file, see [create an authorization model (the schema)](/getting-started/modeling) and [generate data (relationships)](/getting-started/sync-data).

[suggestion]: reduce wordiness; phrases like 'you should be familiar with' are mostly filler. let's just get straight to the point instead!


We'll continue by examining how to create scenarios.
Next, you'll examinine how to create scenarios.

## Creating Test Scenarios

You can create multiple access checks at once to test whether your authorization logic behaves as expected or not.

Besides simple access checks you can also test subject filtering queries and data (entity) filtering with it.

Let's deconstruct the `scenarios`,
Let's deconstruct the `scenarios` configuration.

### Scenarios

Expand Down Expand Up @@ -187,7 +187,7 @@ checks:
push : true
```

Semantics for above check is: whether `user:1` can push to `repository:3`, additional to stored tuples take account that user:1 is owner of repository:3 (`repository:3#owner@user:1`). Expected result for that check it **true** - `push : true`
Semantics for above check is: whether `user:1` can push to `repository:3`, in addition to stored tuples, take into account that user:1 is owner of repository:3 (`repository:3#owner@user:1`). Expected result for that check it **true** - `push : true`

### Depth Configuration

Expand All @@ -211,8 +211,8 @@ checks:
```

**When to use depth:**
- Use a lower depth (e.g., 3-5) for shallow permission hierarchies to improve performance
- Use a higher depth (e.g., 20-50) for deep nested relationships
- Use a lower depth (e.g., 3-5) for a shallow permission hierarchy to improve performance
- Use a higher depth (e.g., 20-50) for deeply nested relationships
- If you encounter "depth not enough" errors, increase the depth value for that specific check

<Note>
Expand All @@ -228,19 +228,19 @@ You can create `entity_filters` within `scenarios` to test your data filtering q
```yaml
entity_filters:
- entity_type: "repository" # entity that you want to filter
subject: "user:1" # subject that you want to perform data filtering
subject: "user:1" # subject for which you want to perform data filtering
depth: 100 # depth limit for permission check (optional, default: 100, minimum: 3)
context: null # additional data provided during an access check to be evaluated
assertions:
push : ["1", "3", "4", "5"] # IDs of the resources that we expected to return
edit : []
```

The major difference between `check` lies in the assertions part. Since we're performing data filtering with bulk data, instead of a true-false result, we enter the IDs of the resources that we expect to be returned
The major difference between `entity_filters` and `checks` lies in the assertions part. Since we're performing data filtering with bulk data, instead of a true-false result, we enter the IDs of the resources that we expect to be returned.

### Subject Filtering

You can create `subject_filters` within `scenarios` to test your subject filtering queries, a.k.a which users can perform action Y or have permission X on entity:Z?
You can create `subject_filters` within `scenarios` to test your subject filtering queries, such as which users can perform action Y or have permission X on entity:Z.

```yaml
- subject_reference: "user"
Expand Down Expand Up @@ -270,7 +270,7 @@ The output of the example provided above is as follows.

You can also test your new authorization model in your local (Permify clone) without using [permify-validate-action] at all.

For that open up a new file and add a schema yaml file inside. Then build your project with, run `make build` command and run `./permify validate {path of your schema validation file}`.
For that open up a new file and add a schema yaml file inside. Then build your project, run `make build` command and run `./permify validate {path of your schema validation file}`.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
For that open up a new file and add a schema yaml file inside. Then build your project, run `make build` command and run `./permify validate {path of your schema validation file}`.
To test locally:
1. Create a schema yaml file.
1. Build your project )(`make build`).
1. To validate the schema, run `./permify validate <path-to-schema-validation-file>`.

3 steps is typically where I draw the line and create an ordered list. Also, I think 'build your project' and 'run make build command' are the same step, so even if we don't break this into discrete steps, we ought to ditch that comma!


If we use the above example schema validation file, after running `./permify validate {path of your schema validation file}` it gives a result on the terminal as:

Expand Down Expand Up @@ -301,7 +301,7 @@ You can find more details about our suggested workflow to handle schema changes

## Need any help ?

Our team is happy to help you get started with Permify. If you'd like to learn more about using Permify in your app or have any questions about it, [schedule a consultation call with one of our account executives](hhttps://calendly.com/d/cj79-kyf-b4z).
Our team is happy to help you get started with Permify. If you'd like to learn more about using Permify in your app or have any questions about it, [schedule a consultation call with one of our account executives](https://calendly.com/d/cj79-kyf-b4z).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have to admit, I would have missed this one! Nice eye.




Expand Down