-
Notifications
You must be signed in to change notification settings - Fork 0
Testing Decisions
As this project involves taking user input through a form and submitting it to a FHIR API (which stores electronic health records in an interoperable format), there are several areas which need to be tested to ensure secure and appropriate functioning. These can largely be broken down into those for the user-facing end (the form and website) and out interaction with the FHIR API.
Our approach with testing is to have high-level integration tests of the react components that the users will interact with, and if required, unit tests for specific functionality of our functions (to allow for increased coverage).The setupTests.ts file, is responsible for setting up the default test environment. In the sections below we'll outline what each is responsible for. As the codebase is small, we have opted for tests to be within the same directory as the production code that they are testing (all tests end with test.ts), if this were to grow larger, having a separate test directory would be warranted.
This is not a test file, but instead configuration of tests. This is where we define our mocks and any test setup that should occur across all tests.
As an example, we have set a global beforeEach function used by jest. This resets any mocks (a function which simulates another function/object) and apply a fetch mock for urls that would be called during integration testing of the ReportForm. This mock processes the request information and gives a known output for each set of results, so that testing doesn't rely on hitting an external API which may be slow.
Loinc is a set of standards that is responsible for standardising healthcare codes across laboratory and clinical systems, the two tests in this file check that the latest release of the codes haven't changed since we persisted them.
These tests cover requests made to the API and the information returned.
To ensure correct processing of the requests, we first clear the database of any patients and the resources that are related to them, as well as practitioners.
These tests are aimed at ensuring that we are interacting with the FHIR API correctly during our processing of data. There is a slight duplication of our ReportForm tests, but we've deemed this acceptable as this allows us to more finely control the testing of our API.
These tests cover unit and end-to-end functionality, just below the surface of the user's full experience of the application. We have had to render the ReportForm component within a context that also allows for the modal hooks to be rendered, for simplicity of testing, we have made a custom react component to do this, rather than rendering the entire index.html.
There is a reasonable amount of helper-code required here to carry out the same steps that the user would carry out for each sub-step of the ReportForm. Almost all interaction needs to be async, and methods have been designed to abstract away setting of fields from drop down values, as well as typing text values and data values.
These tests broadly ensure that error modals are correctly rendered when there has been an issue with a resource within a bundle submitted to the FHIR API, and that we can successfully create a bundle that is submitted to the FHIR api for reports (both with variants, and no variants being reported)
These tests cover the end-to-end functionality tests for the FH results list. This includes setup of the FHIR server data, and then the expected modal contents based on the data from that report and the number of matching patients with that family number.