Client Suite Unit Tests and Unit Test Patterns

[karlnaden]

Summary

Add unit tests for the client suite and also start to build standard unit test infrastructure for Inferno unit tests.

Unit Testing Shared Artifacts

Created a suite rspec [shared_context](https://github.com/inferno-framework/subscriptions-test-kit/blob/client-suite-unit-tests/spec/subscriptions_test_kit/suite_spec_context.rb) that gets included at the top of the unit test to define variables and functions that are expected to be used in most unit tests. Currently, these include

• suite: the suite found in the TestSuite Repository
• suite_id: the suite id
• session_data_repo: session data repository
• validation_url: url for validator requests
• test_session: session data for this suite's run
• run: function to execute a specific runnable
• find_test: function to find a specific runnable within the suite - used to get the runnable to execute. This is an attempt to make a simple interface for finding the test by always loading the full suite and finding a specific test within it.

Questions for reviewers:

• Do these seem like functions and variables that will be used by all inferno unit tests? Anything you would remove because it won't be typically used?
• Any other functions / variables that will usually be used that should be added here?
• Is loading the whole suite and finding a specific test within it the right default pattern? I've seen some unit tests that more directly create tests, but seems like it sometimes causes problems when it references its parents in some way (can find an example if you're not sure what I mean.

Unit Testing Patterns

I created one spec file for a test that includes what I think can be some standard patterns. I included some documentation of them in that class that would probably be moved elsewhere eventually.

Execution with tester-inputs

The test requires tester inputs, specifically an access token and a notification Bundle. The unit test contains a pattern for instantiating the test and executing it.

Wait Tests

This test includes some verification before a wait dialog. The unit test contains a pattern for testing that the wait can be completed as expected.

Questions for reviewers:

• Does this look like the right pattern for wait tests?

Additional Potential Patterns

• Responses from the system under test, e.g., stub_request(:get, "#{export_url}?_outputFormat=application%2Fndjson").to_return(status: 400)
• Requests from the system under test, e.g., post(...) (similar to wait stuff)
• Static method call responses and properties like scratch and suite options, e.g., allow_any_instance_of(test).to(eceive(:suite_options).and_return(ONCCertificationG10TestKit::G10Options::US_CORE_3_REQUIREMENT)
• Stored Tagged requests, e.g., result = repo_create(:result, test_session_id: test_session.id) and repo_create(:request, result_id: result.id, name: 'questionnaire_package', request_body: nil, test_session_id: test_session.id, tags: [DaVinciDTRTestKit::QUESTIONNAIRE_PACKAGE_TAG])
• inspecting messages in results, e.g., [todo - how?]
• look at requests associated with the results, e.g., [todo - how?]
• Dynamically create a test that runs specific sub-logic (used by multiple tests)

Testing Guidance

run rspec using bundle exec rspec