refactor multiple when steps in OCM tests

Signed-off-by: prashant-gurung899 <[email protected]>
owncloud · Nov 25, 2024 · cd175f9 · cd175f9
1 parent 2deeda7
commit cd175f9
Show file tree

Hide file tree

Showing 5 changed files with 28 additions and 110 deletions.
diff --git a/tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md b/tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md
@@ -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)
 

diff --git a/tests/acceptance/features/apiOcm/acceptInvitation.feature b/tests/acceptance/features/apiOcm/acceptInvitation.feature
@@ -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

diff --git a/tests/acceptance/features/apiOcm/createInvitation.feature b/tests/acceptance/features/apiOcm/createInvitation.feature
@@ -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,28 +97,7 @@ 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 "Alice" has created the federation share invitation
     And the user waits "2" seconds for the token to expire
     When "Alice" lists the created invitations
     Then the HTTP status code should be "200"
@@ -187,4 +108,4 @@ Feature: create invitation
         "minItems": 0,
         "maxItems": 0
       }
-      """
+      """
diff --git a/tests/acceptance/features/apiOcm/deleteFederatedConnections.feature b/tests/acceptance/features/apiOcm/deleteFederatedConnections.feature
@@ -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 deleting 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"

diff --git a/tests/acceptance/features/apiOcm/share.feature b/tests/acceptance/features/apiOcm/share.feature
@@ -24,8 +24,8 @@ Feature: an user shares resources using ScienceMesh application
       | shareType       | user       |
       | permissionsRole | Viewer     |
     Then the HTTP status code should be "200"
-    When using server "REMOTE"
-    And user "Brian" lists the shares shared with him without retry using the Graph API
+    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"
     And the JSON data of the response should match
       """
@@ -117,8 +117,8 @@ Feature: an user shares resources using ScienceMesh application
       | shareType       | user          |
       | permissionsRole | Viewer        |
     Then the HTTP status code should be "200"
-    When using server "REMOTE"
-    And user "Brian" lists the shares shared with him without retry using the Graph API
+    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"
     And the JSON data of the response should match
       """
@@ -189,8 +189,8 @@ Feature: an user shares resources using ScienceMesh application
       | shareType       | user       |
       | permissionsRole | Viewer     |
     Then the HTTP status code should be "200"
-    When using server "LOCAL"
-    And user "Alice" lists the shares shared with her without retry using the Graph API
+    And using server "LOCAL"
+    When user "Alice" lists the shares shared with her without retry using the Graph API
     Then the HTTP status code should be "200"
     And the JSON data of the response should match
       """