a7d01d052d
* fix(ui): show password verification for take ownership (PROJQUAY-9658) Co-authored-by: Claude <noreply@anthropic.com> * fix(ui): add fresh login verification to superuser operations (PROJQUAY-9658) Implemented password verification modal for sensitive superuser operations that require fresh login. Added fresh login handling to: - Delete organization - Rename organization - Delete user - Create user - Change user password - Change user email Also fixed UseCreateUser hook to pass error object instead of string to enable fresh login detection. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> * fix(ui): implement global fresh login with request queuing (PROJQUAY-9658) Replaced component-level fresh login handling with centralized axios interceptor approach. All failed requests due to fresh login requirement are now queued and automatically retried after password verification. - Add axios interceptor to catch 401 fresh_login_required globally - Implement request queuing mechanism for pending operations - Add global FreshLoginModal at app root level - Remove component-level useFreshLogin hook from all modals - Close operation modals immediately after submit (request queued if needed) - Add fresh login support for quota management operations * Add Cypress tests for fresh login flow (6 tests) * Address code rabbit reviews * fix(ui): handle fresh login password verification errors - Display error toast when wrong password entered in verification modal - Add centralized fresh login error filtering utility - Add Cypress tests for wrong password and retry scenarios --------- Co-authored-by: Claude <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