Implement e2e (end-to-end) tests via Cypress site wide

[tdonohue]

Describe the bug

Currently, while we have e2e accessibility tests for most pages within the DSpace user interface, we have very few true e2e tests. The existing tests are all written using cypress.io, and can be found in the ./cypress/e2e subfolder:

https://github.com/DSpace/dspace-angular/tree/main/cypress/e2e

As you can see in that subfolder, most of the pages within DSpace have an existing *.cy.ts test file. However, if you open up those files, they are often very minimal and only perform an accessibility scan of the page. See for example the "Browse by Title" tests:
https://github.com/DSpace/dspace-angular/blob/main/cypress/e2e/browse-by-title.cy.ts

Expected behavior

All pages in DSpace should have e2e tests which prove that the basic page actions all work properly. For each page, this would include testing an interaction with everything on that page (e.g. clicking each button/link and ensuring the expected results occur, similarly using each interactive field, submitting forms, etc.) The best examples we have are the tests for Submission & MyDSpace:

• https://github.com/DSpace/dspace-angular/blob/main/cypress/e2e/my-dspace.cy.ts
• https://github.com/DSpace/dspace-angular/blob/main/cypress/e2e/submission.cy.ts

(However, it is worth noting that even the Submission tests and MyDSpace e2e tests could be improved, as they don't click every button or perform every action yet. But, some major actions are being done already in each of those e2e tests.)

Benefits of e2e tests

Adding more e2e tests will provide us with some very useful benefits:

• It will make new PRs easier to review/validate, as the existing e2e tests will validate that no other features have "broken" from the changes. Additionally, we can begin to require new e2e tests for all new features, which will ease requirements on manually testing all new features.
• It will lessen our dependency on an annual "Testathon". While the Testathon will still be useful, it will be less likely to find any obvious bugs (which will have been caught by e2e tests). This means we may be able to limit the scope of the manual testing done in Testathon.
• It will make it easier to validate dependency updates created by @dependabot for dspace-angular. With more e2e tests, we'll be able to catch if simple dependency updates impact any features of the system.

Necessary Developer Knowledge

It is highly likely that this ticket will require many PRs to completely solve. Therefore, we may wish to have different volunteer developer claim different pages to write e2e tests for.

This task can likely be claimed by junior developers who have knowledge of how one (or more) specific pages in DSpace should function.

Developers who wish to claim this task should only need familiarity with Typescript and with Cypress.io. Cypress is quite powerful, and has a relatively easy syntax to learn (see Cypress Docs). You can also easily modify e2e tests and rerun them in Cypress without requiring a full recompilation/rebuild of the Angular UI. Existing DSpace e2e tests can provide guidelines: https://github.com/DSpace/dspace-angular/tree/main/cypress/e2e

More information on running e2e tests locally can be found in our README at https://github.com/DSpace/dspace-angular/?tab=readme-ov-file#e2e-tests

[saschaszott]

Is it worth looking into Cypress Studio (https://docs.cypress.io/app/guides/cypress-studio) to reduce the initial amount of work for creating basic e2e tests?

[tdonohue]

As noted in today's Developers Meeting, anyone can "claim" particular page(s) that they'd like to create e2e tests for.

If a "sub-issue" (see above) does not yet exist, please create one or ask me to do so. I'll then assign it to you. I've pre-created a few important "sub-issues" above, but I will not be creating a "sub-issue" for every page because that is quickly tedious. Instead, I'll gladly create them on demand as developers want to work on e2e tests for specific pages.