You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Dev Phone should be able to remember repetitive conversations from the development loop and automatically have those conversations
Needs to be able to understand which messages belong to which actor (in the event that an application sends multiple messages, for example)
Needs to have a sense of an acceptable/sensible wait time for a message to appear
On failure states (where the expected conversation doesn't match the actual) it should log as much information as possible (which message it failed on, whether it failed due to delay or mismatch data, etc.)
Needs some sort of syntax for saving messages in a sensible way
First thought is an array of objects. Array to show the order of the interaction, objects to hold message + useful metadata (actor, etc)
Considerations
Should there be an option for fuzzy matching, in the event that a developer is making small changes to copy but still wants to test? Alternately, there should just be a way to quickly edit the conversation script, rather than having to re-record again.
The text was updated successfully, but these errors were encountered:
From a "this is a potential testing tool for Twilio users" point of view: Have we considered exposing most of this via a module that can be integrated into existing testing tooling?
i.e. rather than having to build a bunch of UI, data storage, and the rest for this up front, exposing something like an uncomplicated module that can be the client that's sending/receiving messages, and just letting that be called as you would any other module in JavaScript? That might also allow us to figure out the needed interactions and then build the other UX for this on top of that as an additive step rather than doing 100% of it upfront.
The basic parts that I can think of that'd need to be built:
ability to do phone calls
perhaps enable an audio file to be played as the developer's input?
ability to do SMS
ideally probably not super different than the current implementation of how we send a message, just... relatively headless?
ability to do MMS (once this lands in dev phone)
probably same as above?
Maybe my understanding of the offering here is too shallow and this is all not possible, but in general I'd expect that we'd be able to capture responses and do deep assertion checks to make sure that they're what the user would expect back and then allow their test suite to pass/fail if that is/isn't true?
Requirements
Considerations
The text was updated successfully, but these errors were encountered: