...
Other page functionality, such as sorting and filtering - particularly when this shifts to being done on the server-side for other pages.
The home and mappings pages, in a similar vein to how the other pages have been tested.
The process of uploading mappings, and whether the page updates correctly once uploaded or displays the appropriate error messages.
The Details page and its variants, and their corresponding actions (closing accordions etc).
The 404 and unauthorised pages.
The content of the header, footer and sidebar (particularly release information).
Other functionality as it is added, to prevent future regression and improve reliability.
Other future considerations
Ideally, these tests should be run every time frontend changes are pushed to DCB-Admin. This can be done locally for now, but would work particularly well in Continuous Integration, as there would be no need to rely on developers remembering to run the tests before pushing.
Cypress Cloud is a potential solution to this problem.
While code coverage is a useful tool, a manual look at the most common and most important user paths through DCB Admin would be equally useful in determining where to focus our testing efforts.
New DCB Admin work should have accompanying tests written / updated for it going forward to take full advantage of our new approach.
How we are handling network requests and responses
...