Skip to content
Snippets Groups Projects
Commit b58e1045 authored by Rosen Georgiev's avatar Rosen Georgiev
Browse files

Merge branch 'enhance-step-definitions' into 'main'

refactor step definitions

See merge request !22
parents 1c24140a 8bbe3ef6
No related branches found
No related tags found
1 merge request!22refactor step definitions
Pipeline #52491 passed
Showing
with 319 additions and 53 deletions
......@@ -31,47 +31,46 @@ Feature: API -TSA - Policy - :group/:name/:version/evaluation POST
Given we are testing the TSA Policy Api
Scenario: TSA - Evaluate policy synchronously - Positive
Given I load the REST request {Policy.json} with profile {successful_evaluate}
And I execute the policy {/policy/example/test/1.0/evaluation}
When I load the REST request {Policy.json} with profile {successful_message}
And I execute the Policy group {example} name {test} version {1.0} via TSA Policy API
Then the status code should be {200}
And the response is valid according to the {Policy_Evaluate_schema.json} REST schema
And the field {allow} has the value {true}
@bug-policy-35
Scenario: TSA - DID resolution - Positive
Given I load the REST request {Policy.json} with profile {didResolve_evaluate}
And I execute the policy {/policy/example/resolve/1.0/evaluation}
When I load the REST request {Policy.json} with profile {did_key}
And I execute the Policy group {example} name {resolve} version {1.0} via TSA Policy API
Then the status code should be {200}
And the response is valid according to the {Policy_EvaluateDID_schema.json} REST schema
And the field {data.didDocument.id} has the value {did:key:z6Mkfriq1MqLBoPWecGoDLjguo1sB9brj6wT3qZ5BxkKpuP6}
@negative
Scenario: TSA - Evaluate policy with incorrect value - Negative
Given I load the REST request {Policy.json} with profile {unsuccessful_evaluate}
And I execute the policy {/policy/example/test/1.0/evaluation}
When I load the REST request {Policy.json} with profile {incorrect_message}
And I execute the Policy group {example} name {test} version {1.0} via TSA Policy API
Then the status code should be {200}
And the response is valid according to the {Policy_Evaluate_schema.json} REST schema
And the field {allow} has the value {false}
@negative
Scenario: TSA - Evaluate policy with missing body- Negative
Given I execute the policy {/policy/example/test/1.0/evaluation}
And I execute the Policy group {example} name {test} version {1.0} via TSA Policy API
Then the status code should be {200}
And the response is valid according to the {Policy_Evaluate_schema.json} REST schema
And the field {allow} has the value {false}
@negative
Scenario: TSA - Evaluate missing policy - Negative
Then I load the REST request {Policy.json} with profile {successful_evaluate}
Given I execute the policy {/policy/testable/test0/1.0/evaluation}
When I load the REST request {Policy.json} with profile {successful_message}
And I execute the Policy group {example} name {missing} version {1.0} via TSA Policy API
Then the status code should be {404}
And the response is valid according to the {Policy_Evaluate_negative_schema.json} REST schema
And the field {message} has the value {error evaluating policy}
@negative @bug-policy-35
@negative
Scenario: TSA - DID resolution with incorrect did - Negative
Then I load the REST request {Policy.json} with profile {didResolve_missing_method}
And I execute the policy {/policy/example/resolve/1.0/evaluation}
When I load the REST request {Policy.json} with profile {did_missing_method}
And I execute the Policy group {example} name {resolve} version {1.0} via TSA Policy API
Then the status code should be {200}
And the response is valid according to the {Policy_EvaluateDID_negative_schema.json} REST schema
And the field {data.didResolutionMetadata.error} has the value {notFound}
......@@ -26,12 +26,16 @@ Feature: API - TSA - Policy - :group/:name/:version/lock DELETE
Given we are testing the TSA Policy Api
Scenario: TSA - Unlock policy - Positive
When I lock the policy {/policy/example/test/1.0/lock}
And I unlock the policy {/policy/example/test/1.0/lock}
When I lock the Policy group {example} name {test} version {1.0}
And I unlock the policy group {example} name {test} version {1.0}
And the status code should be {200}
# Check if the policy can be executed
When I load the REST request {Policy.json} with profile {successful_message}
And I execute the Policy group {example} name {test} version {1.0} via TSA Policy API
Then the status code should be {200}
@negative
Scenario: TSA - Unlock none existing policy - Negative
When I unlock the policy {/policy/example/non_existing/1.0/lock}
And I unlock the policy group {example} name {non_existing} version {1.0}
And the status code should be {404}
And the field {message} has the value {policy not found}
......@@ -31,20 +31,18 @@ Feature: API - TSA -Policy - :group/:name/:version/lock POST
Given we are testing the TSA Policy Api
Scenario: TSA - Lock policy - Positive
When I lock the policy {/policy/example/test/1.0/lock}
When I lock the Policy group {example} name {test} version {1.0}
Then the status code should be {200}
When I load the REST request {Policy.json} with profile {successful_evaluate}
And I execute the policy {/policy/example/test/1.0/evaluation}
When I load the REST request {Policy.json} with profile {successful_message}
And I execute the Policy group {example} name {test} version {1.0} via TSA Policy API
Then the status code should be {403}
And I lock the policy {/policy/example/test/1.0/lock}
And the status code should be {403}
And the field {message} has the value {policy is already locked}
And I unlock the policy {/policy/example/test/1.0/lock}
And the field {message} has the value {error evaluating policy}
And I unlock the policy group {example} name {test} version {1.0}
@negative
Scenario: TSA - Lock already locked policy - Negative
When I lock the policy {/policy/example/test/1.0/lock}
And I lock the policy {/policy/example/test/1.0/lock}
When I lock the Policy group {example} name {test} version {1.0}
When I lock the Policy group {example} name {test} version {1.0}
And the status code should be {403}
And the field {message} has the value {policy is already locked}
And I unlock the policy {/policy/example/test/1.0/lock}
And I unlock the policy group {example} name {test} version {1.0}
#Copyright (c) 2018 Vereign AG [https://www.vereign.com]
#
#This is free software: you can redistribute it and/or modify
#it under the terms of the GNU Affero General Public License as
#published by the Free Software Foundation, either version 3 of the
#License, or (at your option) any later version.
#
#This program is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#GNU Affero General Public License for more details.
#
#You should have received a copy of the GNU Affero General Public License
#along with this program. If not, see <http://www.gnu.org/licenses/>.
#https://gaiax.vereign.com/tsa/signer/v1/issuerDID
#Author: Georgi Michev georgi.michev@vereign.com
@rest @all @tsa @signer
Feature: API - TSA - Signer Issuer DID - v1/keys GET
As user
I want to see who is the issuer of the keys
So I am better informed
Background:
Given we are testing the TSA Signer Api
Scenario: TSA - Getting Issuer DID - Positive
When I get issuer DID via TSA Signer API
And the status code should be {200}
And the field {did} has the value {did:web:gaiax.vereign.com:tsa:policy:policy:example:returnDID:1.0:evaluation}
\ No newline at end of file
#Copyright (c) 2018 Vereign AG [https://www.vereign.com]
#
#This is free software: you can redistribute it and/or modify
#it under the terms of the GNU Affero General Public License as
#published by the Free Software Foundation, either version 3 of the
#License, or (at your option) any later version.
#
#This program is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#GNU Affero General Public License for more details.
#
#You should have received a copy of the GNU Affero General Public License
#along with this program. If not, see <http://www.gnu.org/licenses/>.
#https://gaiax.vereign.com/tsa/signer/v1/keys
#Author: Georgi Michev georgi.michev@vereign.com
@rest @all @tsa @signer
Feature: API - TSA - Signer keys - v1/keys GET
As user
I want to see what keys are available
So I am able to use them the future
Background:
Given we are testing the TSA Signer Api
Scenario: TSA - Getting all keys from Singer - Positive
When I get all keys via TSA Signer API
And the status code should be {200}
And the response is valid according to the {Signer_GetAllKeys_schema.json} REST schema
And the field {$..type} has the value {["JsonWebKey2020","JsonWebKey2020"]}
And the field {$..publicKeyJwk.kid} has the value {["key1","key2"]}
And the field {$..publicKeyJwk.crv} has the value {["P-256","Ed25519"]}
Scenario: TSA - Getting key1 from Singer - Positive
When I get key {key1} via TSA Signer API
And the status code should be {200}
And the response is valid according to the {Signer_GetKey_schema.json} REST schema
And the field {type} has the value {JsonWebKey2020}
And the field {publicKeyJwk.kid} has the value {key1}
And the field {publicKeyJwk.crv} has the value {P-256}
Scenario: TSA - Getting non existing key - Negative
When I get key {non_existing} via TSA Signer API
And the response is valid according to the {Signer_GetKey_negative_schema.json} REST schema
And the status code should be {404}
#Copyright (c) 2018 Vereign AG [https://www.vereign.com]
#
#This is free software: you can redistribute it and/or modify
#it under the terms of the GNU Affero General Public License as
#published by the Free Software Foundation, either version 3 of the
#License, or (at your option) any later version.
#
#This program is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#GNU Affero General Public License for more details.
#
#You should have received a copy of the GNU Affero General Public License
#along with this program. If not, see <http://www.gnu.org/licenses/>.
#https://gaiax.vereign.com/tsa/signer/v1/presentation/proof
#Author: Georgi Michev georgi.michev@vereign.com
@rest @all @tsa @signer
Feature: API - TSA - Signer presentation proof - v1/presentation/proof POST
As user
I want to check a presentation proof
So I am sure it is valid
Background:
Given we are testing the TSA Signer Api
Scenario: TSA - validate presentation proof - Positive
When I load the request from json {/REST/json/Presentation.json}
When I validate presentation proof via TSA Signer API
And the status code should be {200}
And the response is valid according to the {Signer_PresentationProof_schema.json} REST schema
And the field {proof.verificationMethod} has the value {did:web:gaiax.vereign.com:tsa:policy:policy:example:returnDID:1.0:evaluation#key1}
@wip @bug-signer-#13
Scenario: TSA - validate presentation proof with empty body - Negative
When I set the following request body {{}}
When I validate presentation proof via TSA Signer API
And the status code should be {400}
And the field {message} has the value {missing required payload}
#Copyright (c) 2018 Vereign AG [https://www.vereign.com]
#
#This is free software: you can redistribute it and/or modify
#it under the terms of the GNU Affero General Public License as
#published by the Free Software Foundation, either version 3 of the
#License, or (at your option) any later version.
#
#This program is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#GNU Affero General Public License for more details.
#
#You should have received a copy of the GNU Affero General Public License
#along with this program. If not, see <http://www.gnu.org/licenses/>.
#http://gaiax.vereign.com/tsa/task/v1/taskListStatus
#Author: Georgi Michev georgi.michev@vereign.com
@rest @all @tsa @task
Feature: API -TSA - Task - v1/taskList GET
As user
I want to execute the list of tasks
So I am able to bring the consistency to running multiple asynchronous tasks
Background:
Given we are testing the TSA Task Api
Scenario: TSA - Get status from Task List execution - Positive
When I load the REST request {Policy.json} with profile {did_key}
And I execute the taskList {testList} via TSA Task API
Then the status code should be {200}
And the response is valid according to the {TaskList_Execute_schema.json} REST schema
And I wait for {1000} mseconds
Then I get the current taskList Status via TSA Task API
Then the status code should be {200}
Then I get the current taskList Status via TSA Task API
And the response is valid according to the {TaskList_Status_schema.json} REST schema
And the field {status} has the value {done}
And the field {$..tasks..status} has the value {["done","done"]}
Scenario: TSA - Get status from Task List with three synchronous tasks second fails - Negative
When I set the following request body {{}}
And I execute the taskList {failTestListSync} via TSA Task API
Then the status code should be {200}
And the response is valid according to the {TaskList_Execute_schema.json} REST schema
And I wait for {1000} mseconds
Then I get the current taskList Status via TSA Task API
Then the status code should be {207}
Then I get the current taskList Status via TSA Task API
And the response is valid according to the {TaskList_Status_schema.json} REST schema
And the field {status} has the value {failed}
And the field {$..tasks..status} has the value {["done","failed","failed"]}
Scenario: TSA - Get status from Task List with three asynchronous tasks second fails - Negative
When I set the following request body {{}}
And I execute the taskList {failTestListAsync} via TSA Task API
Then the status code should be {200}
And the response is valid according to the {TaskList_Execute_schema.json} REST schema
And I wait for {1000} mseconds
Then I get the current taskList Status via TSA Task API
Then the status code should be {207}
Then I get the current taskList Status via TSA Task API
And the response is valid according to the {TaskList_Status_schema.json} REST schema
And the field {status} has the value {failed}
And the field {$..tasks..status} has one of the values
| ["done","failed","done"] | ["failed","done","done"] | ["done","done","failed"] |
\ No newline at end of file
#Copyright (c) 2018 Vereign AG [https://www.vereign.com]
#
#This is free software: you can redistribute it and/or modify
#it under the terms of the GNU Affero General Public License as
#published by the Free Software Foundation, either version 3 of the
#License, or (at your option) any later version.
#
#This program is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#GNU Affero General Public License for more details.
#
#You should have received a copy of the GNU Affero General Public License
#along with this program. If not, see <http://www.gnu.org/licenses/>.
#http://gaiax.vereign.com/tsa/task/v1/taskResult
#Author: Georgi Michev georgi.michev@vereign.com
@rest @all @tsa @task
Feature: API -TSA - Task - v1/taskList GET
As user
I want to execute the list of tasks
So I am able to bring the consistency to running multiple asynchronous tasks
Background:
Given we are testing the TSA Task Api
Scenario: TSA - Executing Task with DID resolver and checking the Task Results - Positive
#Execute Task
When I load the REST request {Policy.json} with profile {did_key}
And I execute the Task {didResolve} via TSA Task API
Then the status code should be {200}
And the response is valid according to the {Task_Execute_schema.json} REST schema
#GET Task Result
Then I clear the request body
And I wait for {2000} mseconds
And I get the current Task Result via TSA Task API
Then the status code should be {200}
And the response is valid according to the {Task_ExecuteDID_schema.json} REST schema
And the field {data.didDocument.id} has the value {did:key:z6Mkfriq1MqLBoPWecGoDLjguo1sB9brj6wT3qZ5BxkKpuP6}
Scenario: TSA - Get result from Task List with two synchronous tasks - Positive
When I set the following request body {{}}
And I execute the taskList {testList} via TSA Task API
Then the status code should be {200}
And the response is valid according to the {TaskList_Execute_schema.json} REST schema
And I wait for {1000} mseconds
Then I get the current taskList Status via TSA Task API
And the status code should be {200}
And I get the result of Task {0}
And the status code should be {200}
And I get the result of Task {1}
And the status code should be {200}
And the response is valid according to the {Policy_EvaluateDID_schema.json} REST schema
And the field {data.didDocument.id} has the value {did:key:z6Mkfriq1MqLBoPWecGoDLjguo1sB9brj6wT3qZ5BxkKpuP6}
......@@ -30,23 +30,8 @@ Feature: API -TSA - Task - v1/task GET
Background:
Given we are testing the TSA Task Api
@bug-policy-35
Scenario: TSA - Executing Task with DID resolver and Evaluate the Cache - Positive
Given I load the REST request {Policy.json} with profile {didResolve_evaluate}
And I send the current request as POST to endpoint {/v1/task/didResolve}
Scenario: TSA - Executing Task with DID resolver - Positive
When I load the REST request {Policy.json} with profile {did_key}
And I execute the Task {didResolve} via TSA Task API
Then the status code should be {200}
And the response is valid according to the {Task_Execute_schema.json} REST schema
# Test the Task Result
Then I get the value of {taskID} from the last response and store it in the DataContainer with key {taskID}
Then I clear the request body
And I wait for {2000} mseconds
And I send the current request to endpoint {v1/taskResult} with container value{taskID}
Then the status code should be {200}
And the response is valid according to the {Task_ExecuteDID_schema.json} REST schema
And the field {data.didDocument.id} has the value {did:key:z6Mkfriq1MqLBoPWecGoDLjguo1sB9brj6wT3qZ5BxkKpuP6}
# Test the Cache Service
Then I load object with key {taskID} from DataContainer into currentRequest HEADER {x-cache-key}
And I send the current request as GET to endpoint {https://gaiax.vereign.com/tsa/cache/v1/cache}
And the status code should be {200}
And the response is valid according to the {Task_ExecuteDID_schema.json} REST schema
And the field {data.didDocument.id} has the value {did:key:z6Mkfriq1MqLBoPWecGoDLjguo1sB9brj6wT3qZ5BxkKpuP6}
\ No newline at end of file
And the response is valid according to the {Task_Execute_schema.json} REST schema
\ No newline at end of file
......@@ -30,23 +30,32 @@ Feature: API -TSA - Task - v1/task POST
Background:
Given we are testing the TSA Task Api
@bug-policy-35
Scenario: TSA - Executing Task with DID resolver - Positive
Then I load the REST request {Policy.json} with profile {didResolve_evaluate}
And I send the current request as POST to endpoint {/v1/task/didResolve}
When I load the REST request {Policy.json} with profile {did_key}
And I execute the Task {didResolve} via TSA Task API
Then the status code should be {200}
And the response is valid according to the {Task_Execute_schema.json} REST schema
Then I get the value of {taskID} from the last response and store it in the DataContainer with key {taskID}
Then I clear the request body
And I wait for {2000} mseconds
And I send the current request to endpoint {v1/taskResult} with container value{taskID}
Then the status code should be {200}
Then I get the current Task Result via TSA Task API
And the status code should be {200}
And the response is valid according to the {Task_ExecuteDID_schema.json} REST schema
And the field {data.didDocument.id} has the value {did:key:z6Mkfriq1MqLBoPWecGoDLjguo1sB9brj6wT3qZ5BxkKpuP6}
Scenario: TSA - Executing Task with method and url - Positive
When I set the following request body {{"message": "hello"}}
And I execute the Task {exampleTask} via TSA Task API
Then the status code should be {200}
And the response is valid according to the {Task_Execute_schema.json} REST schema
And I wait for {2000} mseconds
And I clear the request body
Then I get the current Task Result via TSA Task API
And the status code should be {200}
And the field {title} has the value {delectus aut autem}
@negative
Scenario: TSA - Executing Task with non existing task template - Negative
Then I load the REST request {Policy.json} with profile {didResolve_evaluate}
And I send the current request as POST to endpoint {/v1/task/resolve}
When I load the REST request {Policy.json} with profile {did_key}
And I execute the Task {non_existing} via TSA Task API
Then the response is valid according to the {Policy_Evaluate_negative_schema.json} REST schema
And the field {message} has the value {task template not found}
#Copyright (c) 2018 Vereign AG [https://www.vereign.com]
#
#This is free software: you can redistribute it and/or modify
#it under the terms of the GNU Affero General Public License as
#published by the Free Software Foundation, either version 3 of the
#License, or (at your option) any later version.
#
#This program is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#GNU Affero General Public License for more details.
#
#You should have received a copy of the GNU Affero General Public License
#along with this program. If not, see <http://www.gnu.org/licenses/>.
#http://gaiax.vereign.com/tsa/task/v1/taskList
#Author: Georgi Michev georgi.michev@vereign.com
@rest @all @tsa @task
Feature: API -TSA - Task - v1/taskList POST
As user
I want to execute the list of tasks
So I am able to bring the consistency to running multiple asynchronous tasks
Background:
Given we are testing the TSA Task Api
Scenario: TSA - Executing Task List with two synchronous tasks - Positive
When I load the REST request {Policy.json} with profile {did_key}
And I execute the taskList {testList} via TSA Task API
Then the status code should be {200}
And the response is valid according to the {TaskList_Execute_schema.json} REST schema
\ No newline at end of file
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment