Any way to be able to see the exact content of sms sent to a user (inside a test)?

[yanshney]

Hello,

Thank you for you work! I have an app that sends an sms with a verification code to users during signup.

I send it like this: Authy::API.request_sms(:id => user.authy_id)

I was wondering if it is possible to see the exact content of this sms (along with the verification code) during my testing, so I could just directly put the code into the input field when I run my capybara signup test.

Thank you, Yan

[philnash]

Hey @yanshney! Unfortunately the API does not expose the code or the text of the message sent to the user.

However, I wouldn't recommend testing third party services, even as part of your end to end testing. Given the reliance on a network in order to call the API, that you'd be testing a third party library (this one) and the fact that this would trigger an SMS in real life, it doesn't lend itself to good tests.

Instead I would mock the API response for both the sending and verifying part of the test.

What do you think?

[yanshney]

Hi Phil!

Thanks so much for your response!

I know I can use the VCR gem in order to mock the API response, and there is an example online for that, but how would I mock the verification part if I don't know the verification token I need to input?

Thank you, Yan

On Tue, Aug 27, 2019, 8:00 PM Phil Nash notifications@github.com wrote:

Hey @yanshney https://github.com/yanshney! Unfortunately the API does not expose the code or the text of the message sent to the user.

However, I wouldn't recommend testing third party services, even as part of your end to end testing. Given the reliance on a network in order to call the API, that you'd be testing a third party library (this one) and the fact that this would trigger an SMS in real life, it doesn't lend itself to good tests.

Instead I would mock the API response for both the sending and verifying part of the test.

What do you think?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/twilio/authy-ruby/issues/54?email_source=notifications&email_token=AHGYT2ZIS3S3LXFBXDZGGPTQGW5ZJA5CNFSM4IQF4SH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5JO3QY#issuecomment-525528515, or mute the thread https://github.com/notifications/unsubscribe-auth/AHGYT277XY25OJPCN5PEU53QGW5ZJANCNFSM4IQF4SHQ .

[philnash]

VCR can be used to mock an API response, but you could mock closer to your system than that. For example, you can mock the Authy::API.verify method to expect to receive an authy ID and a token and return an object that returns true in response to the ok? method.

You can also test the unhappy path, where you deal with a user entering an incorrect token. You'd still expect the same the same parameters, but the response object would respond false to the ok? method.

Alternatively, if you do want to use VCR, you could record the result of a real use of the API, where you receive the SMS and use the correct code outside of your tests, and set that result up as the VCR tape.

[yanshney]

Hi Phil,

Thank you for your advice, it is really helpful!

I did something like this in my test:

VCR.use_cassette("authy") do current_email.click_link "Confirm this email" #This would also send an sms to user fill_in "token", :with => "436287" (the real token I got in a text message) click_button "Verify" end

I had to set a breakpoint the first time I went through this test and manually input the correct code in my capybara browser.

And my authy.yml content is something like this:

User created successfully SMS token was sent Token is valid.

And it does work, but my question is while it is good that I can now test my signup from the start till the end, is there anything more that I could do to be able to detect if Authy ever stops working in my app?

Thank you, Yan

[philnash]

Glad to hear that the happy path is working for you.

To test the unhappy path, either a wrong code or an API failure, you can continue mocking the response but with different values. You can, for example, create a cassette with a non-200 response or a response where the token was invalid (you can create this one in the same way you generated the happy path, by interrupting but entering the wrong code). You can see what error response will look like in the documentation here.

[yanshney]

I see, thanks a lot for all the help Phil!