Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automated conversations #142

Open
ayyrickay opened this issue Jun 22, 2022 · 1 comment
Open

Automated conversations #142

ayyrickay opened this issue Jun 22, 2022 · 1 comment

Comments

@ayyrickay
Copy link
Collaborator

Requirements

  • 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.
@bnb
Copy link
Collaborator

bnb commented Sep 26, 2022

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants