EKS Endpoint Testing

Last Updated: 05 Aug 2024

Intro

While the preferred testing method for vets-api endpoints in EKS is Datadog Synthetics, VFS members don't currently have access to Datadog. To keep testing uniform and consistent, we are encouraging VFS teams to create a Postman suite to hold their tests. Alternatively, you can record manual test run results in Test Rail.

Creating Postman Collections & Tests

1. Create a Collection
   

   

2. Add Requests to the Collection

3. Use variables for secrets. Variables are useful because they are reusable.

4. Run the Test

5. Share the Collection

Notes:
You can record test examples. This would be helpful for viewing expected test inputs/outputs.

Mock Auth (for dev and local stacks only)

The instructions provided below explain how to simulate authentication, a beneficial method for synthetic testing using Datadog. As of now, when creating tests scoped to Vets API in Datadog, we're confined to browser-based tests if authentication is required. This constraint is due to the fact that the necessary session cookies do not remain active in Datadog's API-only tests.

How to Mock Auth

• On localhost, in idme/configuration.rb or logingov/configuration.rb, set log_credential to true

• Authenticate with the test user on localhost, make sure to use oauth=true in the sign in modal to use sign in service

  • Once authenticated, a new file should be created in your mockdata repo representing the credential you authenticated with

• Take the new file that’s created, and perform the following: encoded_credential = Base64.encode64(credential.to_json)

• Now, on dev or localhost stack, start the sign in service /authorize process
  curl https://dev-api.va.gov/v0/sign_in/authorize?type=idme&code_challenge_method=S256&acr=loa3&client_id=vamock&code_challenge=1BUpxy37SoIPmKw96wbd6MDcvayOYm3ptT-zbe6L_zM=

• Change type=<csp> to the csp you want to log in with

• This curlreturns some params, take note of the state value

• Next, make a call to mocked authentication:
  curl localhost:3000/mocked_authentication/authorize?credential_info=<encoded_credential>&state=<state>

• Use encoded_credential and state from above

• We intentionally don’t use -L option in curl to follow the redirect, since it’ll eventually redirect to the frontend, and we don’t want that

• The result of the curl will tell you the next url to curl, so copy that and follow it (it’ll say ‘you are being redirected to’):

• curl <https://dev-api.va.gov/v0/sign_in/callback?code=<code>&amp;state=<state>>

• This will say ‘you are being redirect to…’, grab the code from the URL: …login/callback?code=<code>

• Finally, make a call to sign in service to swap the code for tokens:

• curl -X POST localhost:3000/v0/sign_in/token -H 'Content-Type: application/json' -d '{"grant_type": "authorization_code", "code_verifier": "5787d673fb784c90f0e309883241803d", "code": "<code>"}

• This will give you back tokens that you can use for Bearer header for arbitrary authenticated routes

Creating a Test User (for Dev)

While the Test User Dashboard (SOCKS proxy access required) has a variety of test users, it would be best for teams to create their own dedicated test users to avoid modifying the data into undesired states. Eg. Team 1 does a post request that modifies a field that Team 2 needs.

1. Create a new user on staging

   1. Go to Sign in => Create an Account with ID.me

   2. Use fake email and password

   3. Enter fake phone number - and ID.me will bypass the verification

   4. Enter fake credit verification info

   5. Follow the steps and redirect back to va.gov

2. Log into staging

   1. This will create a real MPI record for the user on the MPI test stack.

   2. Make sure that oauth=true is set when clicking the Sign in button

   3. Go to https://staging-api.va.gov/v0/sign_in/introspect

   4. Grab the icn. You will need this when mocking the MPI response.

3. For dev, to avoid issues, MPI data for this user should be mocked (via betamocks)

   1. See document to add mocked data for a new user - Important: Be sure to run the rake task on a STAGING instance bundle exec rails mockdata_synchronize:mpi_profile_icn\[<icn>\]` MPI environments are different across stacks, so it’s important to record this mock data in the vets-api staging environment.

4. Record the user in TUD for team awareness

Note: Depending on the specific test needs, it’s also possible that entires for test users will need to be coordinated/created within relevant external services if that are not mocked. E.g. BGS is not mocked on dev, while EVSS is. 

How to Send Authenticated Requests to Vets API

1. In the browser select Sign In (for the respective env. E.g. dev.va.gov or staging.va.gov)

   

2. Sign in via a given identity provider (use your new test user here)

3. After successful login, locate the following cookies in the developer console

   

   1. vagov_anti_csrf_token

   2. vagov_info_token

   3. vagov_access_token

4. On your test in Postman, select cookies

   

5. Manage cookies for the given domain (e.g. dev-api.va.gov, staging-api.va.gov) and add the necessary cookies. Copy/Paste the cookies from your browser into the cookie value

6. The access token will expire after 30 minutes, so the refresh token can be used to obtain another valid access token. Otherwise, values will need to be updated upon expiration for successful testing.

Recording Test Results in TestRail

1. Request access to Test Rail. See TestRail Guide.

2. Create a Project for your Team OR use the Migrate Vets API to EKS project

3. Click on “Test Cases” (top nav bar) => “Add New Test”

4. Add your test case

   

5. Perform manual testing. Note: Test rail does not perform the test run itself, it’s only a place to record

test results.

6. Add Test Run and record your results. See test run examples

Help and feedback

• Suggest content changes to this page.

• Submit new Platform Website content.

• Get help from the Platform Support Team in Slack.

• Submit a feature idea to the Platform.