Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for contextual tuples in model tests #327

Closed
mbarralo opened this issue May 9, 2024 · 5 comments
Closed

Support for contextual tuples in model tests #327

mbarralo opened this issue May 9, 2024 · 5 comments

Comments

@mbarralo
Copy link

mbarralo commented May 9, 2024

Currently the contextual tuples don't seem to be supported in the model tests, although it is possible using API requests with curl, Postman, etc.

Example:

  - name: User can see account from specific branch
    check:
    - user: user:anne
      object: account:1
      contextual_tuples:
        - user: user:anne
          relation: assignee
          object: branch:lisbon
      assertions:
        can_view: true
@PatrickMunsey
Copy link

It appears this is already supported with the tuple_file: field at the global test and per test level. See the example for fga model test

name: Store Name # store name, optional
# model_file: ./model.fga # a global model that would apply to all tests, optional
# model can be used instead of model_file, optional
model: |
  model
    schema 1.1
  type user
  type folder
    relations
      define owner: [user] 
      define parent: [folder]
      define can_view: owner or can_view from parent
      define can_write: owner or can_write from parent
      define can_share: owner
# tuple_file: ./tuples.yaml # global tuples that would apply to all tests, optional
tuples: # global tuples that would apply to all tests, optional
  - user: folder:1
    relation: parent
    object: folder:2
tests: # required
  - name: test-1
    description: testing that the model works # optional
    # tuple_file: ./tuples.json # tuples that would apply per test
    tuples:
      - user: user:anne
        relation: owner
        object: folder:1
    check: # a set of checks to run
      - user: user:anne
        object: folder:1
        assertions:
          # a set of expected results for each relation
          can_view: true
          can_write: true
          can_share: false

@ewanharris
Copy link
Member

Thanks for the issue @mbarralo. @PatrickMunsey is correct that this is achievable using the tuples or tuple_file per test, these tuples will then be used as part of the assertions ran during that test.

Please let us know if you have any further questions about the usage.

@mbarralo
Copy link
Author

Thank you for the reply. For me it seemed more intuitive to think about contextual tuples as something that would be part of the check itself and not part of the tuples that model all checks of the test (hence my example). The distinction of persisted tuples (tuples) and runtime (contextual) tuples could be of value.

@aaguiarz
Copy link
Member

For what is worth, is currently at the test level too, just not at each check level, so you can reuse the same contextual tuples for more than one check:

tests: # required
  - name: test-1
    description: testing that the model works # optional
    # tuple_file: ./tuples.json # tuples that would apply per test
    tuples:
      - user: user:anne
        relation: owner
        object: folder:1
    check: # a set of checks to run
      - user: user:anne
        object: folder:1
        assertions:
          # a set of expected results for each relation
          can_view: true
          can_write: true
          can_share: false

If I understand correctly, if you write one test per check, then you can achieve what you want.

@mbarralo
Copy link
Author

Hello @aaguiarz . True. I guess i can consider the tuples of the tests as contextual and the global tuples the "persisted" ones. Like you said, there are different strategies that can be leveraged. Thanks again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants