test-utils crate helps in invoking postman test collections stored under postman/newman-dir. This directory expects connector level test cases, so the directory structure looks something like this
All the collections maps to a single connector name. Since there is a single connector involved in a given test collection, there is provision for consuming only one single connector's auth at a given time.
We are adding payout specific test cases which would include multiple connectors, and requires the same for running a few test cases (routing + retries). How can this be handled?
Possible Implementation
There could be multiple ways of incorporating these test cases.
Code for consuming auth.toml can be refactored to read multiple variants ConnectorAuthType that are to be read
ConnectorAuthType contains below variants
HeaderKey
BodyKey
SignatureKey
MultiAuthKey
More variants can be added for reading keys of specific connectors.
For example, to handle payouts service cases, we can add PayoutKeys { adyen: SignatureKey, wise: BodyKey }
ConnectorAuthType can have two variants - ConnectorTestCases or ServiceTestCases and these two variants can have distinct way of reading the keys. But the idea remains same, ServiceTestCases will have it's own variants like PayoutKeys. Having this distinction gives more confidence on different type of test cases being added.
...
Have you spent some time checking if this feature request has been raised before?
Feature Description
test-utils
crate helps in invoking postman test collections stored underpostman/newman-dir
. This directory expects connector level test cases, so the directory structure looks something like thisAll the collections maps to a single connector name. Since there is a single connector involved in a given test collection, there is provision for consuming only one single connector's auth at a given time.
We are adding payout specific test cases which would include multiple connectors, and requires the same for running a few test cases (routing + retries). How can this be handled?
Possible Implementation
There could be multiple ways of incorporating these test cases.
Code for consuming auth.toml can be refactored to read multiple variants ConnectorAuthType that are to be read ConnectorAuthType contains below variants
HeaderKey
BodyKey
SignatureKey
MultiAuthKey
More variants can be added for reading keys of specific connectors. For example, to handle payouts service cases, we can add PayoutKeys { adyen: SignatureKey, wise: BodyKey }ConnectorAuthType can have two variants -
ConnectorTestCases
orServiceTestCases
and these two variants can have distinct way of reading the keys. But the idea remains same,ServiceTestCases
will have it's own variants likePayoutKeys
. Having this distinction gives more confidence on different type of test cases being added....
Have you spent some time checking if this feature request has been raised before?
Have you read the Contributing Guidelines?
Are you willing to submit a PR?
None