FI-3222: DTR Client Tests: Use Random Number for Attestation Continuation Links

[degradification]

Description

This ticket updated the Full EHR and SMART App attestation tests to use random ids instead of client id tokens

Important Changes

Removed client id tokens and replaced with random id tokens for the following files

• lib/davinci_dtr_test_kit/client_groups/dinner_static/dtr_full_ehr_launch_attestation_test.rb
• lib/davinci_dtr_test_kit/client_groups/dinner_static/dtr_full_ehr_prepopulation_attestation_test.rb
• lib/davinci_dtr_test_kit/client_groups/dinner_static/dtr_full_ehr_prepopulation_override_attestation_test.rb
• lib/davinci_dtr_test_kit/client_groups/dinner_static/dtr_full_ehr_rendering_enabled_questions_attestation_test.rb
• lib/davinci_dtr_test_kit/client_groups/dinner_static/dtr_full_ehr_store_attestation_test.rb
• lib/davinci_dtr_test_kit/client_groups/dinner_static/dtr_smart_app_prepopulation_attestation_test.rb
• lib/davinci_dtr_test_kit/client_groups/dinner_static/dtr_smart_app_prepopulation_override_attestation_test.rb
• lib/davinci_dtr_test_kit/client_groups/dinner_static/dtr_smart_app_rendering_enabled_questions_attestation_test.rb

lib/davinci_dtr_test_kit/client_groups/resp_assist_device/dtr_questionnaire_rendering_attestation_test.rb

• Fixed Typos
• Update the client id to use a random token value instead this resulted in other changes needed to be made

lib/davinci_dtr_test_kit/mock_auth_server.rb

• Defined a function to determine if the query value being used is a client_id or token value

lib/davinci_dtr_test_kit/dtr_smart_app_suite.rb

• Updated resume_test_route to use the new defined determine query value function

spec/davinci_dtr_test_kit/dtr_questionnaire_rendering_group_spec.rb

• Updated to change client_id usage to token
• Made adjustments to ensure token from dtr_questionnaire_rendering_attestation_test.rb was received and returned

Testing Recommendations

Make sure all unit tests pass (unit tests were not added for this pull request), and the application runs as expected. Run the FullEHR tests to test both expected successes and expected failures. Run the SMART App Test Suite tests to test both expected success and expected failures.

Checklists

Submitter:

• This MR describes why these changes were made.
• This MR is into the correct branch (usually 'main').
• Comment added to the relevant Jira ticket(s) with a link to this MR.
• The relevant Jira ticket has been moved to 'Peer Review' (may be N/A if a Jira ticket is associated with multiple MRs)
• Code diff has been reviewed (it does not contain: additional white space, not applicable code changes, debug statements, etc.).
• Ensure automated tests pass successfully.

Final Merger

• The necessary number of reviews/approvals have been received on this PR and all checklists have been completed.
• The relevant Jira ticket has been moved to 'Done' (may N/A if a Jira ticket is associated with multiple MRs)

[karlnaden]

The changes Look good. While we're doing this, I would change the use of client_id in dtr_questionnaire_rendering_attestation_test.rb because it also means that the client_id input gets added to a group that it wouldn't otherwise be on (all others are involved in communication with inferno, so its already needed). This will ideally require a few other changes

• change the parameter name from client_id to token or something similar that doesn't suggest this is a non-random value
• change the definition of the resume routes in lib/davinci_dtr_test_kit/dtr_smart_app_suite.rb to extract the session identifier from the new parameter name using the extract_token_from_query_params

[karlnaden]

see my comment on one place to replace the use of client_id

[karlnaden]

@vanessuniq @degradification - can you explain the use of a config option here instead of including it in the run block as done in all the other tests? Should this pattern be used everywhere?

[vanessuniq]

This workaround allows for unit testing this test. When the token is included as a variable within the run block, mocking the requests get("#{resume_pass_url}?token=#{token}") or get("#{resume_fail_url}?token=#{token}") in the spec file spec/davinci_dtr_test_kit/dtr_questionnaire_rendering_group_spec.rb will always results in a "wait" status instead of a "pass" or "fail." This happens because the token defined in the unit test will always differ from the token generated in the test's run block.

[karlnaden]

interesting - we haven't typically unit tested attestations because they are so simple. On the fence as to whether I think using this more complicated pattern is worth enabling unit tests. But since we already had them, let's leave in place and call this good. Thanks!

[vanessuniq]

Actually, I found a simpler way, keeping the token in the run block. will reach out to Dalton to refactor and keep it simple before we merge it.

[karlnaden]

one last question.

[karlnaden]

interesting - we haven't typically unit tested attestations because they are so simple. On the fence as to whether I think using this more complicated pattern is worth enabling unit tests. But since we already had them, let's leave in place and call this good. Thanks!