International-Data-Spaces-Association / IDS-testbed

Apache License 2.0
24 stars 32 forks source link

Postman test fails when executed remotely #89

Closed ivakra closed 2 years ago

ivakra commented 2 years ago

Preconditions: Postman collection is preconfigured for remote execution (all remote URLs are set up in the respective collection variables) All tests in the Preconfiguration folder are completed successfully.

  1. Execute the first three tests in the "Validating Preconfigured Setup subsequently: Interaction between Connectors" folder
  2. The three tests pass.
  3. Execute the "Request the Artifact based on the Existing Agreement" test Result: The test fails. Returned response is 401 Unauthorized The Consumer agreement ID collection variable is set to: https://194.141.1.24:8081/api/agreements/bdcc93e0-4dc1-4e84-858f-5cc733263a89 Expected result: The test passes. The Consumer agreement ID collection variable is set to: bdcc93e0-4dc1-4e84-858f-5cc733263a89
jfernandezsqs commented 2 years ago

Hello @ivakra,

I have replicated your precondition. However, the Postman collection that is included in the IDS-testbed has been specifically prepared for this preconfiguration and validating scenario. I guess that you have changed the variables CONNECTORA_URL and CONNECTORB_URL with your network configuration. image

This is not the expected use of the IDS-testbed postman collection.

NOTE: To solve your issue. For your configuration you need to change the following test of the Postman Collection. Execute the "Start Negotiation: POST /api/ids/contract" test changing the line 4 of the Tests section. image Replace localhost to 194.141.1.24. Then execute the "Request the Artifact based on the Existing Agreement" test and it should give a pass result.

ivakra commented 2 years ago

Thank you, Josu! I know that the 'usual' set-up is to run the tests locally, but it is more convenient for me to run the Postman collection from a different environment and I was happy to find that it actually worked pretty well just by changing several variables :) (except for the case I reported). The workaround works excellent and I tried it a bit further by retrieving the value from the environment variable - in this case, I can run the tests against different addresses just by changing the configuration...