How to handle when there is a separate Basic Auth endpoint and api endpoint for each environment
How to handle when there is a separate Basic Auth endpoint that returns a JWT and api endpoint for each environment Here is the use case: 1. There are multiple environments and each environment...
Thanks for the suggestions. At my previous company we set properties in files, but I was hoping I could do something like what Karel suggested using the -E and -P and set properties at run time. Then I don't have to update or store files. I will consider this option, but will have to test it.
I'm interested in your setup suite. How do you have this configured so it always runs first?
to answer your question - I have my setup testsuites disabled, and then I have a 'Setup' testcase with a 'Run Test Case' step in each of my Functional testsuites. The 'Run Test Case' step executes the 'Setup' testcases within the disabled 'Setup' testsuites ( these 'Setup' testsuites are always listed in my project BEFORE the Functional testsuites.
Please see image below - these 'disabled' testsuites are my 'Setup' testsuites. Each one below contains a testcase that does something different:
the 'Generate CRM Access Token' testsuite generates the token needed for later functionaltests
The 'Generate GUIDs' testsuite queries the environment for the GUIDs needed later in the functional tests (these are some of the empty project level properties)
The 'Identiy Test Data Record' testsuite queries the environment for a specific testdata record needed in later tests
The 'Generate Java JWT' generates the token I need for later tests (again, this populates an empty project level property)
My Functional TestSuites look like the following:
So in the image above - SYSLNC001.017 is a functional test suite.
It contains a 'Setup' testcase with 2 teststeps - both of these teststeps are 'Run Test Case' steps which point to the relevant testcases within the disabled 'Setup' testsuites further up in the project hierarchy.
The 017-1 testcase is my functional testcase within the SYSLNC001.017 functional testsuite.
As I already mentioned - the way I do it is that I have a environmentName_properties file which is just a list of name value pairs like the following:
Now - the above list (I've edited it - you can see some static parameters - where there is an attribute separated with it's associated value by the equals sign (e.g. bottom row has 'DB_Database=Reference') and I have some empty properties like the line 'defraexp_ApplicantId@odata.bind='
The way I always do this is to open ReadyAPI, and then load in the envirnmentName.properties file in manually. HOWEVER - if you want to do switch environments WITHOUT bothering launching ReadyAPI, what I have done on some occasion is to launch the testRunner, then paste the content of my properties file into the relevant Project level Properties editable field - see following image:
As you can see - I've pasted all my the content from my properties file into the field.
At this point, you can click 'Get Command Line' and this will generate the command with all those property settings built in. I then took a copy of the testRunner generated line with all the property settings and saved them in a file.
When I did this before - I repeated this process for each of my different environments. - each time I had a new environment, I
1. built up the content of my properties file, then once it was built - I then
2. copied the content into the Project level Properties editable field in the TestRunner form above,
3. selected 'Get Command Line' and copied and saved the content to a separate file.
Eventually i had like maybe 5 txt files that contained the content for the testRunner command for each environment.
Then - each time I wanted to execute my project with a specific environment - I had the correct TestRunner command with all the properties set (both static and dynamic). As I said - for the empty dynamic properties - these are all populated by specific setup testsuites querying the environment when needed via the 'Run TestCase' teststeps in 'setup' testcases within my Functional Testsuites.
Does that help explain the way I do it?
there's bound to be a number of options available - but the above setup is the one i prefer using (probably cos I'm used to it now). The advantage I've found by doing it this way is if you plan your project out correctly, essentially you can build all your ReadyAPI projects so you can lift and shift them to run on any different environment WITHOUT needing to make ANY changes to the testcontent in the project.
I do this with all my ReadyAPI projects now - it's very efficient!
