1

Does anyone have a good working pattern/style/best practice for handling this situation:

I'm trying to develop test cases that are designed to work in either an SIT or UAT environment by simply switching the Test Configuration Parameter: "TestEnvironment" from SIT to UAT...

I'm running into all kinds of roadblocks due to things Tosca CANNOT do... For example, Tosca cannot handle extrapolating test configuration parameters {CP[]} nested inside {XL[]} reference during template instantiation... (i.e. this is invalid: {XL[Preconditions.URL.{CP[TestEnvironment]}]} (it CAN, however handle nested stuff during runtime, for example this is valid at runtime: {B[URL-{CP[TestEnvironment]}]} )

So, the issue I'm trying to resolve is storing the URL, test site ID, User ID, password, and other enviroment specific data such that the test script can properly call data from either SIT or UAT on the fly as needed...

I've tried storing the separate environment data in the test sheets (which doesn't support hiding passwords), I've tried storing data in buffers, but buffers are machine specific, so they would need to be pre-loaded from datasheets anyway) but I feel like the preloading is an ugly kludge.

Clearly, Tricentis intended test configuration parameters to be the key switching mechanism for this... But how do you implement it? Has anyone solved this in an -elegant- way?

Trimble Epic
  • 466
  • 1
  • 3
  • 15

2 Answers2

0

In recent versions TOSCA supports nesting buffers.

Try to buffer the configuration parameter at the beginning and then nesting buffers instead of buffers and configuration parameters.

Lukas Isselbächer
  • 863
  • 7
  • 13
  • I've been playing with buffers since I wrote the OP, and they work great - except for the fact that Tricentis seems to encourage wiping the WHOLE buffer set between test runs (or at least between unrelated tests), which means the buffer stores would have to be reloaded before such runs... and then the question is - reloaded from where? I still feel like having a block of buffer loading test steps at the beginning of test cases is somewhat kludgy... but, it seems to be where evolution is taking me... – Trimble Epic Jul 17 '17 at 11:40
0

You can nest configuration parameters and introduce a pattern for naming them accordingly.

Define all parameters for the environment with a unique identifier at the beginning:

SITUrl, SITUser,...

UATUrl, UATUser,...

You can use another CP called TestEnvironment that you set to "UAT" or "SIT" to switch between them:

{CP[{CP[TestEnvironment]}User]}

{CP[{CP[TestEnvironment]}URL]}

This will always use the user and URL depending on the value set in TestEnvironment.

Kuro Scarlet
  • 36
  • 4
  • My hope was to have TestEnvironment be the only CP needed to make the switch, I'd rather have the data for usernames and URL's in the test sheet (so that we can use classes, and teach the BA's to keep the classes current... user ID's can be kept in a class... (passwords are still a problem)). I feel like it would be a huge mess to try to store whole sets of data in CP's... or even buffers... At least buffers can be pre-loaded from test sheets. – Trimble Epic Jul 17 '17 at 11:38
  • This ended up being pretty close to the way I went with this. I'm using a set buffer block at the beginning of all my test cases that sets up environment settings from one CP called TestEnviroment. – Trimble Epic Jan 22 '18 at 17:31