Page Comparison

...

• The correct rendering of the core DCB Admin pages: agencies, patron requests, groups, hostlmss, sourceBibs and locations - do these pages load as they should, with the data and UI elements we expect?

• The search functionality on the aforementioned DCB Admin pages: can a user find what they’re looking for, and does search searching return the expected results?

  • This is an area for particular development - search has been tested as an example DataGrid action, and filtering and sorting should be tested in the same wayprinciple should be extended to filtering and sorting. It is somewhat more complicated on pages that use server-side searching, sorting and filtering, but it is still possible to test.

• The creation of new groups, and whether new groups are displayed (and displayed with the correct information) on the groups page after their creation.

  • This is an example of an action test: there are many other actions that could be tested within DCB Admin, such as uploading mappings and adding agencies to groups.

  • Action tests should have two main phases:

    • Did the action complete successfully (i.e. were the appropriate requests sent / responses received)?

    • Was the result correctly shown to the user? (i.e. if a new group is created, does it show up in the grid?)

• Login and logout within DCB Admin, whether core UI elements render as they should, and whether they change and render correctly when a user is logged in / logged out.

...

• 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.

• We should consider writing Jest unit tests for greater code coverage and to build resilience (as previously discussed). When we do this, we should adopt the strategy of manual mocking used in ERM/Folio, to help us insulate against API or component changes in future.

• Higher-level actions in Cypress (such as login, etc) should be refactored either into commands or interactors (possibly using these, which are also compatible with Jest integration tests) to promote reusability and consistency throughout our testing approach.

  • We can use before() and after() in our e2e.js file to set up / tear down after tests.

How we are handling network requests and responses

...

• A /cypress directory has been created. It contains the following sub-directories.

  • /downloads - for files downloaded during a test. Not yet used.

  • /e2e - this is where all of our E2E integration tests go. All tests follow the format exampleTest.cy.ts.

  • /fixtures - for Cypress fixtures.

  • /screenshots - Cypress automatically saves screenshots it takes from the tests to this location. These are not to be committed to Git, but are sometimes useful for evidencing test failures or diagnosing an issue. Add this directory to your .gitignore file.

  • /support - contains configuration files for Cypress such as e2e.ts, which manages config for E2E tests, and commands.ts, which is where Cypress custom commands are registered.

    • An example of a custom command is cy.login() - as we generally have to login at the start of most tests, refactoring the necessary code into a command makes sense.

  • /utils - holds any required utility functions.

• Also located within this directory is the Cypress tsconfig.json file, which regulates the behaviour of the TypeScript compiler when dealing with Cypress files.

• Outside of this directoryAt the root of the project, cypress.config.ts manages global Cypress configuration settings.

• Before doing anything with Cypress, you will need to create a cypress.env.json file at the root of the project (same level as package.json) and add the NEXTAUTH_SECRET from .env like so:

  Code Block
  {     "NEXTAUTH_SECRET": "jkdhfkjsahfdjkhsdkjf73" }

  This provides the NextAuth secret to Cypress, which enables it to create the NextAuth cookies necessary for simulating login. Any future Cypress environment variables can go in this file, and the former CYPRESS_USER and CYPRESS_PW variables can be removed from .env, as DCB-930 has changed the method for simulating login.

Preparing and writing tests

...

To run the Cypress tests locally, you have two options. You should first ensure that DCB Admin is running. This Next.js documentation article explains how to get started.

• npx cypress open will open the Cypress application, assuming you have it installed on your machine. This will allow you to choose which tests you would like to run through the Cypress GUI.

• You can also use

  Code Block
  npx cypress run --spec "cypress/e2e/example-test.cy.ts"

  to specify either an individual test, or a set of tests contained within a certain directory.

  • Note that this will run headlessly (in the command line) by default. To force it to run through the GUI, you must add the --headed flag to your command.

  • To run all tests within a certain directory, use the following:

    • Code Block
      npx cypress run --spec "cypress/e2e"

For more information on running Cypress through the command line, please refer to the documentation.

Running coverage reports

Our Cypress setup has code coverage reporting configured automatically through the cypress/code-coverage plugin. This will generate a code coverage report and save it to the coverage directory. However, if you want to see a summary of the code coverage after the tests have been run, run the following command.

...

• patronRequests Refer to groups.cy.ts will serve as for an example of a test for testing a simple, data-grid displaying pagepage with searching and an additional action (the ‘new group’ modal).

• agencies.cy.ts will serve as an example for testing a page with an additional form (the ‘add agencies form’) is a useful template test with lots of informative comments for every testing step.

• patronRequests.cy.ts is a good example of a test for a ‘standard’ page - i.e. one with no additional actions.

Real-World Examples

These examples are useful for understanding the wider context of Cypress testing.

• The Cypress real-world app: this is the definitive official Cypress example application.

• This example of Cypress with Next.js - while focused on component testing, it also has several useful E2E examples.

Debugging

Cypress' documentation has an excellent guide to debugging that can be found here. The standard Developer Tools for your browser can be used in operation with Cypress, making debugging considerably easier.

...

• When a general set of test data is defined, it should be added to the relevant fixtures - these presently use data taken from dcb-dev.

• Before pushing anything to code review, run the relevant tests.

• When a page covered by tests is changed, the relevant tests should always be run and, if necessary, updated to test any new UI elements or functionality.

• We should continually strive for greater test coverage. As such, we should ensure that all new features or pages have corresponding Cypress tests - this will ensure our code coverage isn’t reduced when new features are added.