Testing sending of Text Messages (SMS)

14 views
Skip to first unread message

worldofchris

unread,
Oct 22, 2014, 5:45:01 AM10/22/14
to agile-te...@googlegroups.com
Hi,

Does any one have any experience of / can recommend a way of testing the sending of Text Messages?

I'm looking to use and SMS gateway like https://www.clickatell.com but would like to be able to automate testing for receipt of the message without having to use a physical phone.

Thanks

Chris

Tim Wyatt

unread,
Oct 22, 2014, 8:12:34 AM10/22/14
to agile-te...@googlegroups.com
You need something that can talk SMPP (look it up). IIRC there were some PERL modules that could do this.

The other way I looked to do this was hook up a physical phone that allowed access to its AT command line via a serial connection on USB, and then hack some code to read it.
--
You received this message because you are subscribed to the Google Groups "Agile Testing UK" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agile-testing-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Andy Lawrence

unread,
Oct 22, 2014, 8:48:01 AM10/22/14
to agile-te...@googlegroups.com
What is your intent of your tests? I presume you are not testing the network delivery of SMS messages, but only that you send correctly formatted message requests to your gateway. If so build a mock service and test it is called correctly (right request, right time etc).

Andy

Sent from my phone


----- Reply message -----
From: "Tim Wyatt" <wya...@gmail.com>
To: "agile-te...@googlegroups.com" <agile-te...@googlegroups.com>
Subject: Testing sending of Text Messages (SMS)
Date: Wed, Oct 22, 2014 1:12 PM


YouYou need something that can talk SMPP (look it up). IIRC there were some PERL modules that could do this.

Ivan Sanchez

unread,
Oct 22, 2014, 8:59:44 AM10/22/14
to agile-te...@googlegroups.com
+1

Why would you automate testing all 3rd party systems involved? At most
I'd keep a single integration test just to make sure the real gateway
is responding as expected.

--
Ivan

Tim Wyatt

unread,
Oct 22, 2014, 9:00:07 AM10/22/14
to agile-te...@googlegroups.com
You need something that can talk SMPP (look it up). IIRC there were some PERL modules that could do this.

The other way I looked to do this was hook up a physical phone that allowed access to its AT command line via a serial connection on USB, and then hack some code to read it.

On Wednesday, 22 October 2014, worldofchris <ch...@chrisyoung.org> wrote:
--

worldofchris

unread,
Oct 22, 2014, 9:04:00 AM10/22/14
to agile-te...@googlegroups.com
Thanks for that Andy.

There are three goals for the tests

1. Communicate understanding of intended behaviour
2. Ensure our code works
3. Ensure the solution works end to end

For 2 I agree mocks are what you want.  For 1 and 3 I'd like to be able to test end to end.

Nader Talai has come up with the perfect solution for this which is twilo


"When you buy an SMS-enabled Twilio phone number, you can associate that phone number with a URL. When someone sends a text message to that phone number, Twilio makes an HTTP request to your URL with the body of the message and the sender's phone number. You can then respond to the Message by returning a reply message in the HTTP response to Twilio."

On Wednesday, 22 October 2014 13:48:01 UTC+1, Andy L wrote:
What is your intent of your tests? I presume you are not testing the network delivery of SMS messages, but only that you send correctly formatted message requests to your gateway. If so build a mock service and test it is called correctly (right request, right time etc).

Andy

Sent from my phone


----- Reply message -----
From: "Tim Wyatt" <wya...@gmail.com>
To: "agile-te...@googlegroups.com" <agile-te...@googlegroups.com>
Subject: Testing sending of Text Messages (SMS)
Date: Wed, Oct 22, 2014 1:12 PM


YouYou need something that can talk SMPP (look it up). IIRC there were some PERL modules that could do this.

The other way I looked to do this was hook up a physical phone that allowed access to its AT command line via a serial connection on USB, and then hack some code to read it.

On Wednesday, 22 October 2014, worldofchris <ch...@chrisyoung.org> wrote:
Hi,

Does any one have any experience of / can recommend a way of testing the sending of Text Messages?

I'm looking to use and SMS gateway like https://www.clickatell.com but would like to be able to automate testing for receipt of the message without having to use a physical phone.

Thanks

Chris

--
You received this message because you are subscribed to the Google Groups "Agile Testing UK" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agile-testing-uk+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Pankaj Nakhat

unread,
Oct 22, 2014, 9:04:51 AM10/22/14
to agile-te...@googlegroups.com
Agee; just a test to make sure your service is sending the request. You could possibly write a mock service to simulate SMS sending and that could save it in a file or datbase

Regards,
Pankaj Nakhat

worldofchris

unread,
Oct 22, 2014, 9:15:02 AM10/22/14
to agile-te...@googlegroups.com
Why would I automate testing all 3rd party systems involved?

So that I have a repeatable process for testing the end to end system which doesn't require human intervention to run.

This is _as well as_ not instead of the mocks.

For this I tend to use nock for node, and VCR for Ruby.

Andy Lawrence

unread,
Oct 22, 2014, 9:28:47 AM10/22/14
to agile-te...@googlegroups.com
I suppose I would ask: if this end-to-end test failed what would it tell me, and what could I do about it? Testing things that are outside your sphere of control don't (usually) add value, but they do add complexity.

Just because you can check something doesn't mean you should.

A

worldofchris

unread,
Oct 22, 2014, 9:38:23 AM10/22/14
to agile-te...@googlegroups.com
Thanks for that Andy.

I wouldn't have a lot of confidence putting something live that had only been tested against mocks.

If your system works against mocks but failed when used with the real dependencies then it would tell you about your reliance on things over which you have no control and make you think about how you mitigate against their failure.

it would also tell you how robust those external systems are and whether their failure is in tolerance.  It may be acceptable to, for example, lose one in a hundred messages, it may not be in which case you might need to switch to another vendor.

Just because something is beyond your zone of control does not mean it is outside your sphere of influence.

Cheers

Chris

Matt Wynne

unread,
Oct 22, 2014, 10:59:46 AM10/22/14
to agile-te...@googlegroups.com
There’s a different cadence to when you want to run the tests though.

This post by Nat is relevant: http://www.natpryce.com/articles/000785.html
cheers,

signature.asc

Andy Lawrence

unread,
Oct 22, 2014, 11:44:41 AM10/22/14
to agile-te...@googlegroups.com
Chris

I agree that those things are important to assess, but I would create checks to specifically confirm those things. That's why I asked what you test intent was.

If you are testing a provider's service performance create a test dedicated to do that. If you are testing your code's resilience to poor provider performance then create a test for that. Neither are best served by a generic end-to-end test.

I should add, I wasn't advocating not undertaking an end to end test, only that the value in automating is likely to be relatively low.

worldofchris

unread,
Oct 22, 2014, 12:24:56 PM10/22/14
to agile-te...@googlegroups.com
I should add, I wasn't advocating not undertaking an end to end test, only that the value in automating is likely to be relatively low.

Surely that depends how many times you are going to find yourself running it and how much cost/complexity is involved.

For my money if you're running it more than twice it's worth at least looking at automation to see how much it will cost, hence my original post.

Cheers

Chris

worldofchris

unread,
Oct 22, 2014, 12:46:59 PM10/22/14
to agile-te...@googlegroups.com
Indeed.  Cadence is the key here.
Reply all
Reply to author
Forward
0 new messages