mirror of
https://github.com/quay/quay.git
synced 2026-01-26 06:21:37 +03:00
c6eb6b573d
* test(web): migrate superuser-org-actions.cy.ts to Playwright Migrate Cypress E2E tests for superuser organization actions to Playwright following the project's MIGRATION.md guidelines. Changes: - Add new test file: playwright/e2e/superuser/org-actions.spec.ts - Consolidate 12 Cypress tests into 5 focused Playwright tests - Use real API data instead of mocked fixtures - Auto-cleanup via TestApi fixture Test coverage: - Superuser sees actions column and options menu for organizations - Regular user does not see organization options menu - Superuser can rename organization - Superuser can delete organization - Superuser can take ownership of organization Skipped from migration: - Quota menu tests (already covered by quota.spec.ts) - Fresh login requirement tests (low value, complex to mock) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * test(web): set superuser feature tag Signed-off-by: Brady Pratt <bpratt@redhat.com> * test(web): migrate superuser-messages.cy.ts to Playwright Migrate superuser messages tests from Cypress to Playwright, consolidating 14 original tests into 6 focused, value-add tests. Tests cover: - Non-superuser redirect to organization page - Full CRUD flow: create, view, and delete messages via UI - Error state when API fails to load messages - Loading spinner during message fetch - Read-only superuser can access and view messages - Read-only superuser sees disabled create/delete actions Infrastructure additions: - Add message() method to TestApi with auto-cleanup - Add CreatedMessage interface for type safety - Add SUPERUSERS_FULL_ACCESS feature tag 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * test(web): migrate superuser-user-management.cy.ts to Playwright Consolidates 29 Cypress tests into 11 Playwright tests covering superuser user management functionality. Changes: - Add CreatedUser interface and user() method to TestApi for user creation with auto-cleanup - Add createUserAsSuperuser() to API client using superuser endpoint - Add QuayAuthType and skipUnlessAuthType() helper for auth-type conditional tests - Create user-management.spec.ts with consolidated tests Tests cover: - Create user via UI (Database/AppToken auth only) - User access control based on user type - Change email and password (Database auth only) - Toggle user status (disable/enable) - Delete user - Take ownership (convert user to org) - Fresh login error handling with mocked responses - Send recovery email (MAILING feature) - Auth type visibility Key patterns: - Uses search to find users in paginated list - page.route() only for error scenarios per MIGRATION.md - skipUnlessAuthType() for auth-dependent tests - @feature:SUPERUSERS_FULL_ACCESS tag for all tests 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> * test(web): delete more migrated cypress tests Signed-off-by: Brady Pratt <bpratt@redhat.com> * test(web): migrate superuser-framework Cypress test to Playwright Consolidates 7 Cypress tests into 4 Playwright tests covering: - Superuser navigation to all superuser pages - Navigation section visibility and expansion - Organizations table Settings column and actions menu - Regular user restrictions and redirects Uses real superuserPage/authenticatedPage fixtures instead of mocking. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> * test(web): migrate superuser-service-keys Cypress test to Playwright Consolidates 17 Cypress tests into 5 Playwright tests: - non-superuser redirect to organization page - superuser CRUD lifecycle (create, view, search, update, delete) - error handling when create fails - read-only superuser permission restrictions - bulk select and delete operations Adds service key API methods to Playwright test utilities: - getServiceKeys, createServiceKey, updateServiceKey, deleteServiceKey - TestApi.serviceKey() with auto-cleanup support 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * test(web): migrate superuser-change-log Cypress test to Playwright Migrate superuser-change-log.cy.ts to Playwright with test consolidation: - 7 original tests reduced to 2 focused tests - Access control tests already covered by framework.spec.ts - Loading spinner and empty state tests skipped (low value) - Uses real API calls except for error state (acceptable mock) - No PatternFly class dependencies, uses role-based selectors 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * test(web): migrate superuser-usage-logs Cypress test to Playwright - Consolidate 7 Cypress tests into 2 Playwright tests - Access control tests already covered by framework.spec.ts - Add data-testid="usage-logs-table" to UsageLogsTable component - Tests verify: page header, date pickers, chart toggle, table loading, and filter functionality - Use structural assertions for parallel test safety 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: Brady Pratt <bpratt@redhat.com> * test(web): remove unneeded comments Signed-off-by: Brady Pratt <bpratt@redhat.com> --------- Signed-off-by: Brady Pratt <bpratt@redhat.com> Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
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 applicationfixtures: Mock JSON network responses consumed by Cypresssupport: Additional Cypress configurations eg. Adding commandstest: 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:seedto populate the instance with the test data - Make required changes to the Quay instance
- Run
npm run quay:dumpto update the/cypress/testdirectory with the test data⚠️ Ensure no confidential information is within the test instance when dumping the test data