# Real SMS or mocked verification: which test do you need?

> When to mock the code, when to use your auth provider's test numbers and when to send a real text, with a coverage matrix and a rollout plan.

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.

## 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

1. Pick an existing sign-in account, or a signup identity you can reset.
2. Give the test its own number and a key that can read only that number.
3. Mark the inbox, send the code from your app and wait with a deadline. [One number per parallel test](https://www.phonekit.io/learn/one-number-per-test) covers marks and deadlines.
4. Enter the code and check the final page.
5. Report which stage failed: setup, send, receive, extract or verify.

The [Playwright guide](https://www.phonekit.io/docs/guides/playwright) builds this test, and the [CI guide](https://www.phonekit.io/docs/guides/ci) 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.

---

Source: https://www.phonekit.io/learn/real-vs-mocked-sms-tests