HOW TO TEST
How to Test User Registration.
Authentication A complete testing guide for user registration flows: valid signup, field validation, email verification, duplicate detection, password strength, social signup, API-layer checks, and accessibility.
Registration is the first trust interaction a user has with a product. A single bug here — an unverified duplicate email, a bypassable field requirement, a broken verification link — can corrupt your user base and create security holes that persist for the life of the account. This guide covers the full registration surface: valid signup happy paths, required-field enforcement, email format and uniqueness checks, password strength and confirmation matching, terms acceptance, email verification including resend and expiry, onboarding redirects, social OAuth signup, and API-level backend validation. All test cases are written for a senior QA or SDET audience with Cypress/Playwright in mind.
Risks
Duplicate accounts created for the same email
If uniqueness is enforced only at the UI layer and not the database or API, a race condition or a direct POST to the registration endpoint can create duplicate accounts for the same email address, breaking authentication and user data integrity.
Email verification bypass enabling unverified accounts
If the application grants full access before email verification completes, a registrant with a typo'd or attacker-controlled email address can gain access and may receive sensitive communications intended for someone else.
Weak password allowed despite strength rules
Password-strength validation enforced only in JavaScript can be bypassed by submitting a registration request directly via the API, allowing weak or empty passwords to be persisted if the server doesn't re-validate.
Account enumeration through registration errors
Returning 'that email is already registered' (as opposed to a generic message) tells an attacker which email addresses have accounts, enabling targeted credential-stuffing or phishing attacks.
Username/email injection via unvalidated input
Fields that accept HTML or SQL-special characters without sanitisation expose the application to stored XSS (email displayed in admin UIs) and SQL injection via the name or username fields.
Verification token weak or reusable
Predictable tokens (short numeric codes, sequential IDs) or tokens that remain valid after use can be guessed or replayed to verify email addresses the attacker doesn't control.
Broken social signup creating orphaned accounts
OAuth-based registration that creates a new account on each login (rather than linking to an existing account with the same email) produces orphaned duplicate accounts and fragmented user data.
Test Scenarios
Valid registration with all required fields creates an account
CriticalfunctionalFully automatedSubmit registration with unique email, strong password, and all required fields filled. Assert account is created, verification email sent, and user is redirected to the correct post-registration destination (verification-pending screen or onboarding).
Duplicate email is rejected at both UI and API layers
CriticalnegativeFully automatedAttempt registration with an email address that already exists. Assert the error appears and — critically — make the same attempt via direct POST to the registration API endpoint to confirm server-side enforcement.
Required fields cannot be submitted empty
HighnegativeFully automatedSubmit the registration form with each required field omitted in turn. Assert inline validation messages appear for each empty field and the form does not POST.
Invalid email format is rejected
HighnegativeFully automatedSubmit email values lacking @, missing domain, containing spaces, or exceeding RFC 5321 length limits. Assert server returns a 422/400 with a descriptive error on the email field.
Weak passwords are rejected by both client and server
HighnegativeFully automatedSubmit passwords that violate each strength rule (too short, no uppercase, no number, no symbol) via the UI, then repeat via direct API POST. Both must reject. Confirm the server re-validates independently of the frontend.
Password confirmation mismatch prevents submission
HighnegativeFully automatedEnter a password and a non-matching value in the confirmation field. Assert the form shows a mismatch error before or on submit, and no registration POST is sent.
Terms & conditions checkbox is enforced
MediumfunctionalFully automatedIf the registration flow requires terms acceptance, attempt submission without checking the box. Assert the form blocks submission with a clear error.
Email verification link activates the account
CriticalfunctionalFully automatedComplete registration, intercept the verification email (via test inbox or mail API), click the verification link, and assert the account transitions to verified status. Assert the link is invalidated after use.
Expired verification links are rejected
HighnegativeFully automatedAllow a verification token to expire (or advance server time / expire token in DB), then attempt to use it. Assert a clear 'link expired' message is shown and a resend option is offered.
Resend verification email delivers a new valid link
HighfunctionalFully automatedFrom the verification-pending screen, trigger a resend. Assert a new email arrives, the new link works, and the old link is invalidated or the new token supersedes it.
Social OAuth signup creates a linked account
HighfunctionalManual onlyComplete registration via Google/GitHub OAuth. Assert a user record is created with the correct email, and subsequent login via the same OAuth provider does not create a duplicate account.
Name and username fields sanitise HTML and script input
HighsecurityFully automatedSubmit <script>alert(1)</script> and HTML tags in name, username, and other free-text fields. Assert the input is stored escaped and never rendered as live HTML in the UI, email, or admin dashboard.
Registration form is keyboard-operable and screen-reader accessible
HighaccessibilityManual onlyTab through the entire form, fill it using keyboard only, and verify all fields have visible labels, error messages are announced via aria-live or associated via aria-describedby, and no interaction requires a mouse.
Bulk registration from a single IP is rate-limited
HighsecurityFully automatedSubmit rapid successive registration requests (different emails) via the API. Assert that after a threshold the server responds with 429 Too Many Requests and the limit is not bypassable by changing the User-Agent.
Detailed Test Cases
Preconditions
- Test email inbox accessible via API (e.g. Mailhog, Mailtrap, or a dedicated test account)
- No existing account for the test email address
Steps
- 1.Navigate to /register
- 2.Fill in: first name 'Test', last name 'User', email 'reg-{timestamp}@example.com', password 'P@ssw0rd!2024', confirm password matching
- 3.Accept terms & conditions checkbox if present
- 4.Click 'Create account' / 'Register' button
- 5.Assert redirect to verification-pending screen or onboarding
- 6.Poll test inbox for the verification email (timeout 30 s)
- 7.Click the verification link from the email
- 8.Assert account transitions to 'verified' state (banner, redirect, or API GET /me shows emailVerified: true)
Expected result
Account is created, verification email arrives within 30 s, and clicking the link activates the account.
Test data
- email: reg-<timestamp>@example.com (unique per run)
- password: P@ssw0rd!2024
- firstName: Test, lastName: User
Edge Cases
Email address with + alias (e.g. user+test@example.com)
Many email clients support + aliasing. The server should accept this as a valid address. Some applications incorrectly strip the + suffix or reject it as invalid.
Email address with international/unicode characters
RFC 6531 permits non-ASCII local-parts. Servers that only validate ASCII email may incorrectly reject valid international addresses or store them in a corrupted form.
Extremely long password (e.g. 500 characters)
bcrypt has a maximum input length of 72 bytes. Passwords longer than this are silently truncated, meaning two different passwords that share the first 72 bytes will hash identically — a silent security flaw.
Registration with same email but different casing (User@Example.COM vs user@example.com)
Email addresses are case-insensitive by spec. An application that treats these as different addresses allows duplicate accounts for the same inbox.
Submitting the form twice rapidly (double-click or network lag)
A double-submit can create two registration requests in flight simultaneously. If the server lacks idempotency checks, two accounts or two verification emails can result.
Back button after successful registration creates confusion
Pressing back after successful registration may re-render the form pre-filled. Submitting again should not create a second account.
Verification link opened in a different browser or device
The verification link should work regardless of which browser or device opens it — it is a stateless token, not tied to the originating session.
Registration during account deactivation window
If a previously-deleted or deactivated account's email is used to re-register, the application should handle this cleanly — either blocking, reactivating, or creating fresh, with no data leakage from the old account.
Empty trailing/leading whitespace in email field
Users often paste email addresses with a trailing space. The server should trim whitespace before validation and storage, or it will create an account that the user can never log into.
Terms checkbox state not preserved across validation errors
If form validation fails and the page re-renders, the terms checkbox must not be unchecked. Losing checkbox state forces the user to re-accept and is frustrating.
Automation Ideas
Parameterised API registration test matrix
Drive a table of {email, password, firstName, expectedStatus, expectedErrorField} through the registration API. Covers valid, invalid, duplicate, and edge cases without UI overhead. Run as part of every PR build.
Tools: playwright, cypress, rest-assured, postman
Test inbox integration for email verification
Use a programmable test inbox (Mailhog for local, Mailtrap for staging) to intercept verification emails, extract the token or URL, and assert activation in the same test run. Eliminates manual email checking.
Tools: playwright, cypress
Database-state assertion after registration
After registration, query the users table directly to assert the correct fields are set: email (trimmed, lowercased), password (hashed, never plaintext), emailVerified (false), createdAt timestamp within range.
Tools: playwright, cypress
Token expiry test via DB manipulation
In the test environment, directly update the token expiry column to the past, then exercise the expired-link flow. Avoids sleeping and is deterministic.
Tools: playwright, cypress
Rate-limit smoke test in CI
Send a burst of registration requests in a loop and assert the 429 appears within the expected window. Gate this behind a tag so it runs in the rate-limit test suite only, not every commit.
Tools: k6, playwright
XSS field injection sweep
Loop through a list of XSS payloads for each free-text field (name, username, company). Assert none execute when the registered user's profile is viewed. Use a CSP violation report listener as a secondary check.
Tools: playwright, cypress
Accessibility audit on the registration form
Run axe-core against /register and assert zero violations at the WCAG 2.1 AA ruleset. Combine with a keyboard-tab-order assertion (verify tabIndex sequence) using playwright-testing-library.
Tools: axe-core, playwright, pa11y
Common Bugs
Duplicate emails allowed via race condition
Two simultaneous POST /register requests with the same email both pass the 'is email taken?' check before either inserts a row. Without a unique database constraint as the final guard, both accounts are created.
Impact: Two accounts share one inbox; neither user can reliably log in, and password-reset emails go to both.
Verification email not sent on re-registration after deletion
When a previously-deleted user re-registers with the same email, some systems skip sending the verification email because the email address 'looks familiar', leaving the account permanently unverified.
Password hash stored as plaintext
A misconfigured ORM, a migration error, or a logging statement can cause the raw password to be written to the database or log file instead of the hashed value.
Impact: Complete credential exposure for all users if the database or logs are breached.
Verification link points to wrong environment
Verification emails built using a hardcoded base URL (e.g. production) while the link was sent from staging, or vice versa. Users click the link and land on the wrong environment's error page.
Password field value echoed in the HTTP response
The registration API response body includes the submitted password, either in plaintext or base64-encoded, leaking it to the browser and any logging proxy.
Username/name fields accept only ASCII — silent truncation
Users with non-ASCII names (accents, CJK characters) find their name truncated or replaced with '??' characters in the UI and confirmation email.
Terms checkbox required only client-side
The terms acceptance is validated in JavaScript but not enforced on the server. A direct API call with termsAccepted: false creates an account without any legal record of acceptance.
Resend verification sends old (expired) token
The resend flow retrieves the existing token from the database and resends it rather than generating a fresh token. Users who wait for the first link to expire and request a resend receive a link that is also already expired.
Email trimming inconsistency causes login failure
Registration trims leading/trailing spaces from the email, but login does not (or vice versa). A user who pasted their email with a trailing space during registration cannot log in without also pasting the space.
Useful Tools
End-to-end registration flows, email inbox polling via API, and form accessibility assertions.
Component and E2E registration tests with easy network interception for watching POST requests.
Automated WCAG 2.1 AA audit of the registration form, including label, contrast, and ARIA checks.
Generate unique, realistic test email addresses, names, and passwords for each test run.
Catch verification emails in development/staging without delivering to real inboxes. Query via API.
API-level registration tests — duplicate email, weak password, and field validation bypasses.
Active scan for XSS, injection, and enumeration vulnerabilities in the registration endpoint.
Rate-limit testing — send a burst of registration requests and assert 429 response at the threshold.
// Related resources
Glossary terms
- Authentication
- OAuth 2.0
- RBAC
- XSS (Cross-Site Scripting)
- SQL Injection
- OWASP
- Rate Limiting
- Boundary Value Analysis
- Equivalence Partitioning
- Exploratory Testing
- Regression Test
- Smoke Test
- Test Data Management
- Schema Validation
- Accessibility
- WCAG
- ARIA Attributes
- Screen Reader Testing
- Validation
- Email Verification
- Negative Testing
- Session