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)
When testing Twilio functions locally you need to construct a global scope that contains a
Twilioobject that has aResponseproperty, as well as a globalResponseproperty, 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 dateResponseclass.The
Responseclass from the runtime-handler is still effectively a mock, as it is a development version of the realResponsethat 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 aGlobalTwilioobject somehow) then function-templates and customers could use theResponseobject that matches their runtime-handler version in their tests.(see also RUN-4441)