15

Does Twilio have any "test" telephone numbers that I can use to emulate outbound calls? For example, I'd like to be able to test my app to the fullest, getting back asynchronous responses (like I would normally expect to) for calls that are busy, answering machines, out-of-order, invalid numbers etc.

There are a few numbers you can use for SMS messages - but these all return simple, immediate responses, and not the kind of asynchronous ones you'd expect through voice calls that are being handled through TwilXML.

How am I supposed to test all this functionality without making calls to tons of "live" numbers?

nickhar
  • 19,981
  • 12
  • 60
  • 73
Brad
  • 11,262
  • 8
  • 55
  • 74
  • Give the support team a call. They provided us with credits that allowed us to test some of the functionality you describe. I know there is at least one twilio developer on SO, so this will likely be picked up by them. _Note: I'm in no way affiliated with Twilio here but I am a customer who wanted to do the same._ – nickhar Apr 12 '14 at 01:55
  • It's been a while, but I haven't ignored or given up on this. Twillo doesn't seem to have any good solution. It's been a complete blocker as I won't deploy a solution that I can't leverage a good test against ahead of time. – Brad May 12 '15 at 13:44

2 Answers2

4

Twilio evangelist here.

Have you looked at using Test Credentials? These are a special set of credentials and magic phone numbers that you can use to tell Twilio via the REST API to emulate things like making an outbound phone call. Using the magic phone numbers you can get Twilio to return specific responses (like trying to dial an international phone number without the right permissions).

For testing webhook endpoints (the URL's in your webhook that Twilio is going to make its HTTP requests to), you can use the same testing techniques you would to test a normal web app.

gvlasov
  • 18,638
  • 21
  • 74
  • 110
Devin Rader
  • 10,260
  • 1
  • 20
  • 32
  • I looked at those numbers. Unless I missed something - they don't cover the type of, depth, complexity and specific test cases I mentioned. – Brad Apr 13 '14 at 02:34
  • So you might have to combine using test credentials with simulating Twilio HTTP webhook requests. Test credentials should let you test things like invalid numbers, or other cases where the REST API is going to return a 400 BAD REQUEST error. For scenarios like simulating a status callback HTTP request, Twilio does not have anything specific built in, but you can create mock HTTP requests that contain the same parameters Twilio would normally pass and just fill them with mock data. Does that help? – Devin Rader Apr 13 '14 at 03:33
  • 3
    No - it kinda doesn't. I don't know how you'd expect someone to go out the door with a full-fledged, professional, load-tested application without being able to go through a "real" test cycle. I'm doing a "call tree" app and need to deal with things like "busy-signals" and failure cases which I'd need to retry. How can I deploy a wide-scale app without a decent level of testing for all the "edge cases". I can't make hundreds of recipients home and cell phones my guinea pigs - but it sounds like I won't be able to throw a reasonable test at the system otherwise... – Brad Apr 14 '14 at 12:50
  • Hey Brad. Sorry you're not finding this helpful. From my own experience, I've very rarely had a need to have Twilio specifically be the HTTP client that makes the requests to my application URLs in order to test them. For me, any HTTP Client will do. I normally spin up something like Fiddler or POSTMan and have it send a HTTP request that contains the same form encoded parameters that Twilio would, but with the specific the parameters values I want to test. (continued) – Devin Rader Apr 14 '14 at 17:55
  • For example if I want to test if my application is handling a busy signal correctly, I would have POSTMan (for example) send an HTTP request to my application URL and include in that request the CallStatus parameter set to 'busy'. This simulates the HTTP request Twilio would make to the URL you've set for the StatusCallback parameter. Of course I could use a Unit Testing framework to automate this test for me. – Devin Rader Apr 14 '14 at 17:58
  • 2
    I know - thanks - but I am *VERY* hesitant to go out the door with a "full-scale, battle-hardened" app that has never undergone full integration testing with it's actual endpoint. – Brad Apr 15 '14 at 13:00
  • Stripe actually does exactly this VERY well for Credit Card payment processing. There is a "magic" credit card number - if you use it - it'll behave just like a real one - with one small (important) exception: Transactions to them will only appear when you use a TEST API key to access the service instead of your real-one. You can do complete end-to-end front and back-end test of the entire stack. – Brad Apr 16 '19 at 19:47
4

I was looking for the same thing, because I need to test external calls to my internal IPs, and because I don't want the phone ringing all the time! While I find it disappointing that Twilio doesn't provide this functionality, Devin's response seems reasonable.

I was wondering if someone else had created the set of HTTP interactions in a more comprehensive manner, and found this:

https://github.com/minddog/twilio-emulator

Trying it out now. Perhaps in the future Twilio could add basic callback, not necessarily a full set of Twiml cases that would have to be passed in for each interaction.

orbfish
  • 7,381
  • 14
  • 58
  • 75