mirror/opencloud
1
0
Fork 0
mirror of https://github.com/opencloud-eu/opencloud.git synced 2026-01-26 06:50:36 -05:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #10626 from owncloud/tests-ocm-refactor-steps

Browse Source 
[tests-only][full-ci] refactor multiple when steps in OCM tests
This commit is contained in:
Prashant Gurung
2024-11-28 16:41:10 +05:45
committed by GitHub
parent 2e40f9905c cbf2b4f393
commit b1b9e7b77f
5 changed files with 94 additions and 108 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
tests/acceptance/bootstrap/OcmContext.php
View File

@@ -251,7 +251,7 @@ class OcmContext implements Context {
}
/**
* @When the user waits :number seconds for the token to expire
* @When the user waits :number seconds for the invitation token to expire
*
* @param int $number
*

4
tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md
View File

@@ -250,8 +250,8 @@ The expected failures in this file are from features in the owncloud/ocis repo.
#### [OCM. federated connection is not dropped when one of the users deletes the connection](https://github.com/owncloud/ocis/issues/10216)
- [apiOcm/deleteFederatedConnections.feature:39](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiOcm/deleteFederatedConnections.feature#L39)
- [apiOcm/deleteFederatedConnections.feature:66](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiOcm/deleteFederatedConnections.feature#L66)
- [apiOcm/deleteFederatedConnections.feature:21](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiOcm/deleteFederatedConnections.feature#L21)
- [apiOcm/deleteFederatedConnections.feature:67](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiOcm/deleteFederatedConnections.feature#L67)
#### [OCM. server crash after deleting share for ocm user](https://github.com/owncloud/ocis/issues/10213)

14
tests/acceptance/features/apiOcm/acceptInvitation.feature
View File

@@ -31,19 +31,17 @@ Feature: accepting invitation
Scenario: two users can accept one invitation
Given using server "LOCAL"
And "Alice" has created the federation share invitation
When using server "REMOTE"
And "Brian" accepts the last federation share invitation
And using server "REMOTE"
And "Brian" has accepted invitation
When "Carol" accepts the last federation share invitation
Then the HTTP status code should be "200"
And "Carol" accepts the last federation share invitation
And the HTTP status code should be "200"
Scenario: user tries to accept the invitation twice
Given using server "LOCAL"
And "Alice" has created the federation share invitation
When using server "REMOTE"
And "Brian" accepts the last federation share invitation
Then the HTTP status code should be "200"
And using server "REMOTE"
And "Brian" has accepted invitation
When "Brian" tries to accept the last federation share invitation
Then the HTTP status code should be "409"
And the JSON data of the response should match
@@ -100,7 +98,7 @@ Feature: accepting invitation
And the config "OCM_OCM_INVITE_MANAGER_TOKEN_EXPIRATION" has been set to "1s"
And "Alice" has created the federation share invitation
When using server "REMOTE"
And the user waits "2" seconds for the token to expire
And the user waits "2" seconds for the invitation token to expire
And "Brian" tries to accept the last federation share invitation
Then the HTTP status code should be "400"
And the JSON data of the response should match

155
tests/acceptance/features/apiOcm/createInvitation.feature
View File

@@ -31,33 +31,6 @@ Feature: create invitation
}
}
"""
When "Alice" lists the created invitations
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "array",
"minItems": 1,
"maxItems": 1,
"items": {
"type": "object",
"required": [
"expiration",
"token"
],
"properties": {
"expiration": {
"type": "integer",
"pattern": "^[0-9]{10}$"
},
"token": {
"type": "string",
"pattern": "%fed_invitation_token%"
}
}
}
}
"""
@issue-9591
Scenario: user creates invitation with valid email and description
@@ -88,37 +61,6 @@ Feature: create invitation
}
}
"""
When "Alice" lists the created invitations
And the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "array",
"minItems": 1,
"maxItems": 1,
"items": {
"type": "object",
"required": [
"expiration",
"token",
"description"
],
"properties": {
"expiration": {
"type": "integer",
"pattern": "^[0-9]{10}$"
},
"token": {
"type": "string",
"pattern": "%fed_invitation_token%"
},
"description": {
"const": "a share invitation from Alice"
}
}
}
}
"""
Scenario Outline: user creates invitation with valid/invalid email
@@ -155,30 +97,9 @@ Feature: create invitation
Scenario: user cannot see expired invitation tokens
Given using server "LOCAL"
And the config "OCM_OCM_INVITE_MANAGER_TOKEN_EXPIRATION" has been set to "1s"
When "Alice" creates the federation share invitation
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "object",
"required": [
"expiration",
"token"
],
"properties": {
"expiration": {
"type": "integer",
"pattern": "^[0-9]{10}$"
},
"token": {
"type": "string",
"pattern": "%fed_invitation_token%"
}
}
}
"""
And the user waits "2" seconds for the token to expire
When "Alice" lists the created invitations
And "Alice" has created the federation share invitation
When the user waits "2" seconds for the invitation token to expire
And "Alice" lists the created invitations
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
@@ -187,4 +108,72 @@ Feature: create invitation
"minItems": 0,
"maxItems": 0
}
"""
"""
Scenario: user lists created invitation
Given using server "LOCAL"
And "Alice" has created the federation share invitation
When "Alice" lists the created invitations
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "array",
"minItems": 1,
"maxItems": 1,
"items": {
"type": "object",
"required": [
"expiration",
"token"
],
"properties": {
"expiration": {
"type": "integer",
"pattern": "^[0-9]{10}$"
},
"token": {
"type": "string",
"pattern": "%fed_invitation_token%"
}
}
}
}
"""
@issue-9591
Scenario: user lists invitation created with valid email and description
Given using server "LOCAL"
And "Alice" has created the federation share invitation with email "brian@example.com" and description "a share invitation from Alice"
When "Alice" lists the created invitations
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
{
"type": "array",
"minItems": 1,
"maxItems": 1,
"items": {
"type": "object",
"required": [
"expiration",
"token",
"description"
],
"properties": {
"expiration": {
"type": "integer",
"pattern": "^[0-9]{10}$"
},
"token": {
"type": "string",
"pattern": "%fed_invitation_token%"
},
"description": {
"const": "a share invitation from Alice"
}
}
}
}
"""

27
tests/acceptance/features/apiOcm/deleteFederatedConnections.feature
View File

@@ -16,7 +16,16 @@ Feature: delete federated connections
And "Brian" has accepted invitation
When user "Brian" deletes federated connection with user "Alice" using the Graph API
Then the HTTP status code should be "200"
When user "Brian" searches for federated user "alice" using Graph API
@issue-10216
Scenario: users should not be able to find federated user after federated user has deleted connection
Given using server "LOCAL"
And "Alice" has created the federation share invitation
And using server "REMOTE"
And "Brian" has accepted invitation
And user "Brian" has deleted federated connection with user "Alice"
And using server "LOCAL"
When user "Alice" searches for federated user "Brian" using Graph API
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
@@ -34,16 +43,8 @@ Feature: delete federated connections
}
}
"""
@issue-10216
Scenario: local user should not be able to find federated user after federated user has deleted connection
Given using server "LOCAL"
And "Alice" has created the federation share invitation
And using server "REMOTE"
And "Brian" has accepted invitation
And user "Brian" has deleted federated connection with user "Alice"
And using server "LOCAL"
When user "Alice" searches for federated user "brian" using Graph API
When user "Brian" searches for federated user "Alice" using Graph API
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
@@ -77,8 +78,7 @@ Feature: delete federated connections
| shareType | user |
| permissionsRole | Viewer |
And using server "REMOTE"
When user "Brian" deletes federated connection with user "Alice" using the Graph API
Then the HTTP status code should be "200"
And user "Brian" has deleted federated connection with user "Alice"
When user "Brian" lists the shares shared with him without retry using the Graph API
Then the HTTP status code should be "200"
And the JSON data of the response should match
@@ -112,8 +112,7 @@ Feature: delete federated connections
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
When user "Alice" deletes federated connection with user "Brian" using the Graph API
Then the HTTP status code should be "200"
And user "Alice" has deleted federated connection with user "Brian"
And using server "REMOTE"
When user "Brian" lists the shares shared with him without retry using the Graph API
Then the HTTP status code should be "200"