Page Comparison

...

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

...