Real SMS or mocked verification: which test do you need?
Mock the code to test your form. Use your auth provider's test numbers to test the integration. Send a real text when you need to know the code actually arrives.
Phonekit team Updated
Match the test to the failure you want to catch
"Does the form explain an invalid code?" and "Does our sender reach a real phone?" need different tests.
| Test | Catches | Misses |
|---|---|---|
| Mocked response | Input rules, loading, error text, navigation | Sender settings, delivery, message format |
| Auth provider's test numbers | Your integration with the provider's test mode | Any real sending or receiving |
| Real number receiving a real text | Sending, delivery, code extraction, sign-in | Other numbers, countries and networks |
Use the cheapest test that answers the question. A fast invalid-code test is worth keeping even when you also run a real one.
Run each test where it helps
| When | Run | Who fixes a failure |
|---|---|---|
| Every change to the form | Mocked success and error states | App developer |
| Auth integration changes | Provider test-mode flow | Auth integration owner |
| Sender settings change | One real text, end to end | App and delivery owner |
| Release or scheduled staging run | Real text in that environment | Release or QA owner |
Keeping the real-text test separate means a delivery problem doesn't hide a form bug, or the other way round.
Finish the real test at the outcome
Receiving the text is one checkpoint. The test should enter the code and check where the user lands: the account page after sign-in, or the new number in settings after a phone change. Use a number outside any provider test-number list, and confirm the app is using the sender and environment you mean to test.
Add one real test, then grow
- Pick an existing sign-in account, or a signup identity you can reset.
- Give the test its own number and a key that can read only that number.
- Mark the inbox, send the code from your app and wait with a deadline. One number per parallel test covers marks and deadlines.
- Enter the code and check the final page.
- Report which stage failed: setup, send, receive, extract or verify.
The Playwright guide builds this test, and the CI guide runs it on every push.
Questions
Should we remove our mocked tests?
No. Keep them for invalid input, expired codes, resend controls and loading states. Add one real text for delivery. Most tests don't need to send SMS.
What does a passing real-text test prove?
That this account, number, sender and step worked in that run. Keep those details with the result so later failures are comparable. It says nothing about other numbers, countries or services.
Can a provider's test mode prove delivery?
It proves your integration with that mode. Fixed-code test numbers never send a text, so to prove a code arrives, use a real number and a mode that sends.
Keep reading
- Real SMS in your testsTest everything your app texts end to end, from sign-in codes and invite links to confirmations and two-way replies, with real US phone numbers, including real SIM lines, in Playwright, Cypress and CI.
- Build the real-text testA complete Playwright SMS test: receive a fresh code with the Phonekit SDK, submit it in the browser, and assert the signed-in account.
- Provider test numbersA Firebase phone-auth acceptance recipe that preserves real app verification, receives an SMS through Phonekit, and distinguishes fictional-number coverage.
- One number per parallel testMake SMS tests repeatable: mark the inbox before you send, give each parallel worker its own number, budget the whole test and report the stage that failed.