Hi @adrianth and OpenTest team!
I've been looking through the code base of the server, and within my organization we've been thinking about modifying the underlying implementation of the test-repo in order to enforce inmutability to the data assets within it. The idea behind environments is pretty powerful to enforce DRY principles (in some sense), and we are looking forward to some feedback to the following idea:
What about isolating the data and data-env access so that data is "inmutable" within the OpenTest scope (changes in the environment don't change the reference to it) and data-env is "mutable" such that it's tied to the environment and falls back to a default environment.
Ensuring inmutability for data boosts developer productivity given that it is assumed to be the same (within the OpenTest scope), and everytime a developer looks at a $data, they already know that it is static throughout runs. And to tackle the convenience of having several environments for the same script, let's just change it to a different keyword, instead of using $data, let's use $data-env or some derivation of $env-{}.
I think that this idea maintains the core motivation behind data-env while also isolating mutable assets through runs, giving a better developer experience.
What do you think?
Hi @adrianth and OpenTest team!
I've been looking through the code base of the server, and within my organization we've been thinking about modifying the underlying implementation of the test-repo in order to enforce inmutability to the
dataassets within it. The idea behind environments is pretty powerful to enforce DRY principles (in some sense), and we are looking forward to some feedback to the following idea:What about isolating the
dataanddata-envaccess so thatdatais "inmutable" within the OpenTest scope (changes in the environment don't change the reference to it) anddata-envis "mutable" such that it's tied to the environment and falls back to a default environment.Ensuring inmutability for
databoosts developer productivity given that it is assumed to be the same (within the OpenTest scope), and everytime a developer looks at a $data, they already know that it is static throughout runs. And to tackle the convenience of having several environments for the same script, let's just change it to a different keyword, instead of using $data, let's use $data-env or some derivation of $env-{}.I think that this idea maintains the core motivation behind
data-envwhile also isolating mutable assets through runs, giving a better developer experience.What do you think?