Ability to coordinate use of shared resources (users) across test #53
Description
Often times, we are given credentials for an application under test.
Rather than storing them in the AppConfig we could store them in a data store of some sort (DB).
Why a DB?
Sometimes those credentials must be shared, but there is a limit as to how many sessions can be active per user. An example is, the application (re)stores the state of a user’s actions across sessions. This can cause issues with parallel execution, as parallel sessions could affect each other.
With a DB we could define multiple creds under the same“credential name”, such that a query for the user will get the next available uid for that “credential name”.
Then the test(er) can “check out” the credentials for a period of time and know that they “own it” for that time. Once done, they can “check back in” or the timer will expire, making the user available again.
Note: Passwords are expected to be stored into a Vault