Make real SMS verification part of your test
Your test reaches Send code. Phonekit receives the message at a company test number, your runner reads it, and the browser completes verification. Keep that whole journey in the test you already use.
Cover the journey your user completes
A QA engineer can automate the form and still pause at the SMS step. The code arrives on a phone, someone reads it, and the test resumes after a manual handoff. With Phonekit, the test has its own receiving number and reads the arriving message inside the runner.
Your application still sends through its existing provider. The browser follows its normal signup or sign-in screen. Phonekit supplies the receiving side, and the test asserts that verification reached the expected application state.
Example acceptance-test journey
- Open the app and enter the assigned QA number.
- Request the verification message through the app.
- Read the newly received code through Phonekit.
- Enter it and assert the account page or verified state.
Add the receiving step to your stack
Start with the browser or authentication test you already maintain. The SDK fits into JS/TS runners; other stacks can use the HTTP API from their test host.
| Your stack | Working starting point |
|---|---|
| Playwright | Browser test with SDK receipt |
| Cypress | Server-side task and browser assertion |
| Supabase Auth | Request, receive and verify an OTP |
| Firebase Auth | Real receipt alongside fictional-number tests |
| Twilio Verify | Verification request through acceptance |
| iOS simulator / XCUITest | Native test-runner receipt |
Scroll horizontally to see all columns.
Take the same test into CI
Once the test succeeds locally, its receiving step stays the same. CI supplies a scoped key, the assigned number, and the application's test URL. The GitHub Actions recipe shows the workflow file, browser installation and number concurrency together.
Choose the account state deliberately: an existing sign-in account, a fresh registration, or a verified-number change. Give concurrent workflows independent numbers, or serialize the jobs using the same one.
Start with one valuable delivery check
Pick the flow your team wants confidence in after a release or sender configuration change. Keep fast form/error-state tests alongside it. A real-receipt test adds a check of sending, receipt, message format and final verification; the coverage guide helps decide where it belongs.
When a run fails, report the stage: setup, send, receive, extract, or verify. That gives the developer a useful place to begin instead of a generic “OTP test failed.”
Questions you may have
Can we use our current SMS provider?
Yes. The application keeps its sender configuration, and the test enters a Phonekit number as its destination. Check a real send through the intended provider and environment, then automate receipt. Phonekit does not need to become the sender.
Does this work with fixed test OTPs?
Fixed-code modes remain useful for fast application tests. Add a separate real-receipt flow outside the provider's fixed-number mapping when you want to exercise actual delivery. The coverage comparison explains the boundary.
How many test numbers do we need?
Count independently running verification workflows, including overlapping CI jobs. Assign a number to each, or serialize those sharing an inbox. Two requests to one number can cross even when both use a fresh cursor.
Can this verify links as well as numeric codes?
Received messages include detected links as well as an optional OTP. A test can retrieve the message, follow the intended link, and assert the application outcome. Treat the link as sender data and use it within the workflow you intended.