How to handle when there is a separate Basic Auth endpoint and api endpoint for each environment

srixon ,

the solution depends on the structure of your tests and also on the authentication methods.

If you can satisfy the authentication with any method from Auth manager, that would be the easiest way to go.

Otherwise you can e.g. dedicate a test case for authentication. In such test case you can invoke the authentication, process its response and save into a property. You can avoid scripting if you use property transfer test step. Also you can use a Run Test Case step to invoke it wherever needed.

Maybe you can close this thread (which relates to endpoint configuration) and start a new one for authentication if needed.

Best regards,

Karel

Hey srixon 

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:

Generate CRM Access Token=eyJ0eXAiOiJ
Exports Token Value=eyJ0eXAiOiJKV1
Exports_CM=https://management-integration.azurewebsites.net/
Exports_Auth=https://authentication-integration.azurewebsites.net/
CRM=https://defra-cus.crm4.dynamics.com/
defraexp_Organisation@odata.bind=
defraexp_ApplicantId@odata.bind=
defraexp_CertifierOrganisation@odata.bind=
resource=https://.crm4.dynamics.com
client_id=2fcc6119-c8a0-44a3-8c12-
client_secret=Z%2AePjVgTc2U_
grant_type=client_credentials
EXP_resource=e621ab05-3417-448
EXP_client_id=e621ab05-3417-448
EXP_client_secret=a%2BOPsfWybHR
EXP_username=exportsadministrator@sandpit.onmicrosoft.com
EXP_password=Rojo5166!
EXP_grant_type=password
LogicApp=https://northeurope.logic.azure.com:443/
LogicApp2=https://northeurope.logic.azure.com:443/workflows/triggers/manualp-GpmOmxvBLuMWcYD3mhk
DevEndpoint=https://dev.azure.defra.cloud
TestEndpoint=https://tst.azure.defra.cloud
X-Api-Key=WNvLMgN{`,&
X-Api-Client=TESTERS
DB_Host=127.0.0.1
DB_Port=1433
DB_User=sa
DB_Database=Reference

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='

I populate the 'defraexp_ApplicantId@odata.bind=' property by executing one of the Setup Testsuites.

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!

Cheers,

Rich