Forum Discussion

nastester's avatar
nastester
Regular Contributor
2 years ago

Speed up API test integration

I have a smoke test project that executes APIs and then asserts that values change/update on the frontend after each API call. 

I am using the ReadyAPI integration to execute the APIs within TestComplete. 

 

Is there a way to speed up how long it takes to execute the API? Or a better way to do this? I need to execute a single POST API and then run a TestComplete test to verify, then another API, etc. 

 

Thanks in advance

2 Replies

  • Kitt's avatar
    Kitt
    Regular Contributor

    EDIT: TestComplete isn't really built to handle this scenario, if indeed you need to check the UI after every API request. If you are running an individual ReadyAPI test case through TestComplete, TC has to initialize, authenticate, run, log, and close the ReadyAPI test runner (plugin) each time - so if you're attempting to jump back and forth between a ReadyAPI test and a TestComplete UI test, it can become wildly inefficient.

     

    IMO, there are only a few cases where TC/ReadyAPI integration becomes useful:

    1. When you want to obtain a value from the UI and use it in your API request, [see here].
    2. Running a full suite of ReadyAPI tests (Post/Put/Patch/Delete) before or after your TestComplete tests, so the ReadyAPI Runner only has to launch once.

     

    If you NEED to capture a value from an API response to use in a UI test, my recommendation would be to run all of your API tests directly from ReadyAPI and save off your desired response values to a test file (.xlsx) that can be consumed and verified during the TestComplete (UI) portion of your testing using [Keyword Parameters] and/or [Keyword Data Access] or [Keyword - ReadFromExcel]

     

    If you absolutely have to check the UI after every API request, I think the fastest runtime solution would be to create a PowerShell script, using [Invoke-RestMethod]. But even using this approach, you’d still have to save a PowerShell script for every request OR use aqFile.Replace (or similar) to update the Powershell script before the next request.

     

    Depending on how you authenticate, something like:

    $webURL="https://<enter your api endpoint here>"
    $urlToEncode = $webURL
    $encodedURL = [System.Web.HttpUtility]::UrlEncode($urlToEncode) 
    
    $Key = "<enter your key here>"
    $Secret = "<enter your secret here>"
    $Ver = "v1"
    $Date = Get-Date
    $Date = $Date.ToUniversalTime()
    $DateStr = $Date.ToString("ddd, dd MMM yyyy HH':'mm':'ss 'GMT'")
    $Nonce = -join (((48..57)+(65..90)+(97..122)) * 80 |Get-Random -Count 32 |%{[char]$_})
    
    $body = "{
    `n  `"account_number_from`": `"123456789`",
    `n  `"account_number_to`": `"987654321`",
    `n  `"amount`": 1000000.01
    `n}"
    
    $RawMessage = ("CompanyX" + " " + $Key + $webURL + $Nonce + $DateStr + $Ver + $Body)
    $RawMessage
    
    $hmacsha = New-Object System.Security.Cryptography.HMACSHA512
    $hmacsha.key = [Text.Encoding]::UTF8.GetBytes($Secret)
    $signature = $hmacsha.ComputeHash([Text.Encoding]::UTF8.GetBytes($RawMessage))
    $signature = [Convert]::ToBase64String($signature)
    
    $headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"
    
    $headers.Add("X-Auth-Signature", $signature)
    $headers.Add("Content-Type", "application/json")
    $headers.Add("Ocp-Apim-Subscription-Key", $Key)
    $headers.Add("X-Auth-Nonce", $Nonce)
    $headers.Add("X-Auth-Timestamp", $DateStr)
    $headers.Add("X-Auth-Version", $Ver)
    
    $response = Invoke-RestMethod $webURL -Method 'POST' -Headers $headers -Body $body -v
    $response | ConvertTo-Json

    My biggest justifications for keeping ReadyAPI/TestComplete tests separate, in most cases, and allowing each project to use their own respective test runner, is that - for starters, you can avoid having do anything I mentioned above - with the exception of saving a test file in ReadyAPI & assigning those values as Project.Variables in TestComplete. Also, by managing a single shared test file or folder across multiple projects, it becomes much easier to control, reuse, troubleshoot, and verify the test data and variables that are used in all of your projects.

    • nastester's avatar
      nastester
      Regular Contributor

      Thank you for the well thought out reply! Appreciate it