mirror of https://github.com/quay/quay.git synced 2026-01-26 06:21:37 +03:00

Files

jbpratt e21a9caae2 test(web): fix service-keys tests failing due to past expiration dates (#4768 )

Replace hardcoded expiration date '2025-12-31T23:59' with dynamically
generated future date. The tests were failing with "Expiration date
must be in the future" validation error since it's now 2026.

Added getFutureExpirationDate() helper that returns a date 1 year
from now in the required datetime-local format.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>

2026-01-02 17:21:30 -05:00

e2e

test(web): fix service-keys tests failing due to past expiration dates (#4768 )

2026-01-02 17:21:30 -05:00

fixtures

chore: remove deprecated reCAPTCHA support (#4690 )

2025-12-05 08:10:43 -06:00

support

test(web): migrate some tests and improve framework (#4760 )

2025-12-23 16:35:54 -06:00

test

feat(ui): add repository activity heatmap (PROJQUAY-9353) (#4398 )

2025-10-30 10:27:47 -05:00

README.md

ui: Teams and members (PROJQUAY-4569) (#2007 )

2023-08-29 15:03:56 -04:00

README.md

E2E Testing

Why e2e test?

End to end tests ensure the application pages and components work properly together from an end user perspective. We use Cypress as the e2e testing framework, where we provide a URL of the running application and it will arrange, act, and assert on the application behavior.

How to e2e test?

Directory structure

e2e: Contains test files, each corresponding to a page in the application
fixtures: Mock JSON network responses consumed by Cypress
support: Additional Cypress configurations eg. Adding commands
test: Seed data for the test instance of Quay

Testing strategy

Tests are divided into two scenarios: using server or stubbed responses. Requests that reach out directly to a Quay instance are called server responses while requests that are mocked are called stubbed responses. A full comparison between the two can be found here but it can be summarized as follows:

Server responses

More likely to work in production
Requires seeding the Quay instance
Much slower
Difficult to test edge cases
Use sparringly

Stubbed responses

Control of responses to test edge cases
Fast
No guarantee stubbed responses match the real responses
Use for majority of tests

The recommended practice is to mix and match server and stubbed responses. A single spec will have server responses testing the critical paths of the application and then stubbed the rest.

Updating the Quay seed data

Both the database and blob data must be stored to seed the Quay instance. This data is stored in the /cypress/test directory. Running npm run quay:seed will seed the local instance of Quay with the test data.

To make changes to the test data:

Have a local instance of Quay running via docker-compose (make local-dev-up)
Run npm run quay:seed to populate the instance with the test data
Make required changes to the Quay instance
Run npm run quay:dump to update the /cypress/test directory with the test data

⚠️ Ensure no confidential information is within the test instance when dumping the test data