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
When testing Twilio functions locally you need to construct a global scope that contains a Twilio object that has a Response property, as well as a global Response property, in order to match the environment that Functions run in. In the function-templates repo we achieve this with setup and teardown methods with a mocked and out of date Response class.
The Response class from the runtime-handler is still effectively a mock, as it is a development version of the real Response that the deployed Functions runtime-handler uses, but it is up to date with the version of the runtime-handler that is being used. If we exposed this class (and perhaps a GlobalTwilio object somehow) then function-templates and customers could use the Response object that matches their runtime-handler version in their tests.
(see also RUN-4441)
The text was updated successfully, but these errors were encountered:
When testing Twilio functions locally you need to construct a global scope that contains a
Twilio
object that has aResponse
property, as well as a globalResponse
property, in order to match the environment that Functions run in. In the function-templates repo we achieve this with setup and teardown methods with a mocked and out of dateResponse
class.The
Response
class from the runtime-handler is still effectively a mock, as it is a development version of the realResponse
that the deployed Functions runtime-handler uses, but it is up to date with the version of the runtime-handler that is being used. If we exposed this class (and perhaps aGlobalTwilio
object somehow) then function-templates and customers could use theResponse
object that matches their runtime-handler version in their tests.(see also RUN-4441)
The text was updated successfully, but these errors were encountered: