Test Cases: Email Verification
Module: Authentication & Identity - Email Verification
Context: Verification is often tied to Registration or explicit requests.
Backend: Shared utilities generateVerificationToken, verifyMemberByToken.
Test Cases
TC-VER-01: Verify Email via Link
| Step | Action | Expected Result |
|---|---|---|
| 1 | Register a new user (which generates verification token). | Token exists in Member table. |
| 2 | Extract verificationToken. | - |
| 3 | Access Verification URL (e.g., GET /verify?token=...). | (Note: Depending on implementation, this might be a frontend route that calls an API). |
| 4 | API Action. | Backend validates token, updates Member.status (e.g., transitions from PENDING_VERIFICATION to ACTIVE or PENDING_APPROVAL). |
| 5 | DB Verification. | verificationToken is cleared or marked used. emailVerified (if exists) set to true. |
TC-VER-02: Verification Token Expiry
| Step | Action | Expected Result |
|---|---|---|
| 1 | Generate a token but wait for expiry (or mock DB to set expiry in past). | - |
| 2 | User clicks link. | - |
| 3 | API Response. | Error indicating token validity window has passed. |
| 4 | User Experience. | Prompt to "Resend Verification Email". |
TC-VER-03: Resend Verification Email
| Step | Action | Expected Result |
|---|---|---|
| 1 | User requests "Resend Verification" (if flows exist). | - |
| 2 | Check Backend. | New token generated replacing the old one. New expiration time set. |
| 3 | Check Email. | New email received. |