OTP Testing for Developers: Using Real Numbers in Test Flows

Start with the normal path: a user enters a number, receives a code, enters it, and is verified. Then test the cases around it. What happens if the code is wrong three times? If it expires? If the user asks for a new one? If two codes are sent close together, which one is valid?

Check your messages too. Make sure the text is short, says what it is for, and does not look like spam.

Real SMS is not instant. Delivery can take seconds or longer, and sometimes a message does not arrive. Your app should show a clear countdown, allow a resend after a sensible wait, and offer another method when possible.

Test what the user sees when the text provider returns an error. A silent failure is worse than an honest message.

Limit how often a code can be requested per number and per device. Count failed attempts and lock the flow for a while after too many. Test these limits on purpose. They protect you from cost and from misuse.

Many auth tools let you set fixed test numbers with fixed codes. They are fast and free, and they are good for automated tests. They do not tell you how a real network behaves.

A real number tests the full path. With SMS Activate you can rent a number, run your flow against it, and read the code on the dashboard or through the API. The API documentation lists the endpoints and the billing rules.

Real numbers cost a small amount per activation. Keep real-number tests for staging and for a short list of end-to-end checks. Only test against services you own or have permission to test. Do not point tests at third-party sites.

Test happy path, wrong code, expiry, resend and rate limits. Test a slow delivery. Test a failed send. Keep codes short-lived. Log events without logging the codes themselves.

Write the cases down before you run them. Happy path: request a code, receive it, enter it, and sign in. Wrong code: enter a wrong code and check the error message and the attempt counter. Expired code: wait past the expiry and check that the old code is rejected.

Resend: request a second code and confirm that the first one stops working, if that is your rule. Rate limit: send several requests quickly and check that your limit applies. Country format: test numbers with and without the country code.

Record the time each message takes to arrive. A table of requests and arrival times shows you whether your delivery is slow only at certain moments.

Real numbers cost a small amount per activation, so use them for the cases that need the real path, and use fixed test numbers for the rest. Run real-number tests on a schedule, such as before a release, not on every commit.

Log the outcome of each test with the date and the build. If a test fails, repeat it once before you raise it as a bug, because carrier delays can mislead.

Separate your bugs from delivery problems. If the message never left your system, it is your bug. If it left and did not arrive, check your sender settings and the route. Share the details with your SMS provider, including timestamps and the exact number.

A short test report helps: the date, the build, the number of requests, the number of codes that arrived, the slowest and the fastest arrival time, and any errors. Keep to what you measured, and avoid claims about carriers in general.

If you find a slow route, note the country and the time of day. Patterns across several days tell you more than one bad run.