Prácticas recomendadas para las pruebas

Desarrollar una acción para la plataforma Actions on Google a menudo implica implementar Dialogflow para su comprensión del lenguaje natural (CLN) y entrega de Dialogflow, que controla la lógica de tu acción. Tener pruebas en la base de código ayuda a garantizar que el rendimiento de la Acción sea el que se espera en producción.

Cuando implementes pruebas de unidades, de integración o de extremo a extremo para tu Acción, debes considerar el agente de Dialogflow y la entrega como componentes separados.

Un diagrama de flujo procede de una consulta del usuario a Actions on Google, Dialogflow y un webhook de entrega, y finalmente regresa al usuario.

Figura 1: Diagrama de flujo que describe los sistemas que se deben considerar para las pruebas

Prueba un agente de Dialogflow

El agente de Dialogflow y la entrega se prueban como componentes independientes. En las siguientes subsecciones, se describe cómo puedes conceptualizar y probar el agente de Dialogflow para tu acción.

Dialogflow como sistema de búsqueda de entrada y salida

Tu agente de Dialogflow es responsable de tomar la consulta de un usuario, hacerla coincidir con un intent y extraer las entidades predefinidas de la consulta. Para interactuar con la entrega, el agente pasa un mensaje que contiene el intent coincidente, sus parámetros y los metadatos de Actions on Google.

Como desarrollador, tú controlas la configuración del agente de Dialogflow, como la estructura de intents y entidades. Los metadatos de Actions on Google provienen de Actions on Google, y se puede suponer que contienen los datos correctos para realizar pruebas.

Cuando realices pruebas, enfócate en hacer que tu agente sea capaz de extraer correctamente los parámetros de los intents y de hacer coincidir las consultas con los intents. Este enfoque proporciona una métrica cuantificable para evaluar el rendimiento del agente. Para calcular esta métrica, prepara y usa casos de prueba individuales o un conjunto de validación.

Un agente de Dialogflow se puede representar con una consulta de texto como entrada y un intent más los parámetros del intent extraído como salida.

Figura 2: Representación de Dialogflow como sistema de búsqueda de entrada y de salida

Pruebas de unidades

Para tu agente de Dialogflow, puedes escribir pruebas en las que cada caso espere una consulta de texto como entrada y produzca metadatos del intent como salida. Estos metadatos deben (como mínimo) contener el nombre del intent coincidente y una lista de parámetros coincidentes.

El extremo detectIntent de la API de Dialogflow toma la consulta de texto como una entrada y produce una salida estructurada que contiene el nombre del intent resuelto y los parámetros extraídos. Este resultado es útil para evaluar el rendimiento de coincidencia de intents del agente. Para obtener una referencia completa de otros campos útiles, consulta la referencia de QueryResult.

Una prueba de ejemplo se ve de la siguiente manera:

it('choose_fact', async function() {
  // The `dialogflow` variable is an abstraction around the API that creates
  // and sends payloads to Dialogflow.
  const resJson = await dialogflow.detectIntent(
    'Tell me about the history of Google');
  expect(resJson.queryResult).to.include.deep.keys('parameters');
  // Check that Dialogflow extracted required entities from the query.
  expect(resJson.queryResult.parameters).to.deep.equal({
    'category': 'history',
    // Put any other parameters you wish were extracted
  });
  expect(resJson.queryResult.intent.displayName).to.equal('choose_fact');
});

Este fragmento usa Mocha y Chai. Consulta el ejemplo completo de la prueba de unidades de Dialogflow escrita en Node.js para Datos sobre Google.

Los archivos de prueba se pueden ejecutar en paralelo porque la API de Dialogflow acepta un sessionId como argumento. Como resultado, puedes tener una zona de pruebas separada para cada conversación mientras usas un solo cliente de la API de Dialogflow.

Debido a que realizas solicitudes a la API de Dialogflow, es posible que se genere un cargo si alcanzas tu cuota de llamadas gratuitas. Consulta Cuotas y límites para obtener más información.

Pruebas de integración

El extremo detectIntent de la API de Dialogflow también activa las entregas de terceros. Como tal, es posible escribir casos de prueba que abarquen la integración entre el agente y la entrega de Dialogflow.

La principal diferencia entre la escritura de pruebas de integración y de unidades para Dialogflow es que, en la prueba de integración, puedes confirmar las respuestas que provienen del webhook, así como el intent de Dialogflow y la extracción de entidades.

Consulta el ejemplo completo de una prueba de integración escrita en Node.js en el repositorio de Datos sobre Google.

Prueba un webhook de entrega de Dialogflow

El agente y la entrega de Dialogflow se prueban como componentes separados. En las siguientes subsecciones, se describe cómo conceptualizar y probar la entrega de tu acción.

Entrega como un sistema de entrada y salida de JSON

Tu código de entrega de Dialogflow espera solicitudes y produce respuestas en formato JSON. Como resultado, puedes probar el código de entrega si lo piensas como un sistema de entrada y salida JSON. La solicitud contiene metadatos de Dialogflow y de Actions on Google, por lo que tiene todo lo necesario para activar un controlador de intents particular en tu entrega.

Para probar la activación de un controlador de intents, envía una solicitud JSON (entrada) a tu acción. Esta solicitud se pasa a tu entrega, a la que se puede acceder en Internet. Luego, la entrega produce una respuesta JSON (resultado), que se puede evaluar para la validación.

Una entrega se puede representar con la entrada de solicitud JSON y la salida de respuesta JSON de webhook.

Figura 3: Representación de una entrega como sistema JSON de entrada y salida

Pruebas de unidades

Piensa en el código del webhook de entrega como un sistema que acepta una entrada JSON y produce una salida de JSON. El proceso de prueba de una acción se simplifica para proporcionar una solicitud a tu entrega y verificar el JSON resultante.

Esto te brinda la libertad de alojar la entrega de forma local y enviar solicitudes HTTP de forma local para realizar pruebas. Si usas la biblioteca cliente de Node.js de Actions on Google, también puedes enviar solicitudes JSON directamente a la capa de middleware de la biblioteca cliente.

Si pruebas el código de webhook con entradas JSON y recibes las salidas de JSON esperadas, puedes decir con una confianza razonable que las partes que controlas funcionan de forma correcta. Puedes suponer que Dialogflow y Actions on Google funcionan correctamente porque generan las cargas útiles de JSON correctas. Este aislamiento proporciona un modelo de programación simplificado para escribir pruebas.

A continuación, se incluye un resumen general del proceso de prueba:

  1. Usa el simulador en la Consola de Actions para obtener las solicitudes JSON de cada paso en un caso de uso. Guárdalos como archivos JSON. También puedes compilar esas solicitudes por tu cuenta con la información de la documentación de referencia de webhook.
  2. Escribe pruebas para invocar el webhook con estas cargas útiles.
  3. Para cada prueba, asegúrate de que el JSON de respuesta contenga los elementos esperados.

Además, este modelo te permite probar la entrega de Dialogflow en una configuración de integración continua porque el extremo de entrega se puede ejecutar de forma local y la API de Dialogflow tiene un concepto integrado de sesiones.

Una prueba de ejemplo se ve de la siguiente manera:

it('yes-history', function() {
  expect(jsonRes.payload).to.have.deep.keys('google');
  expect(jsonRes.payload.google.expectUserResponse).to.be.true;
  expect(jsonRes.payload.google.richResponse.items).to.have.lengthOf(3);
  expect(jsonRes.payload.google.richResponse.suggestions).to.have
    .deep.members([
      {'title': 'Sure'}, {'title': 'No thanks'},
    ]);
});

El fragmento anterior usa Mocha y Chai. Consulta el ejemplo funcional completo escrito en Node.js en el repositorio de Facts About Google.

Diseña una entrega que se puede probar en unidades

El código de webhook suele contener una lógica empresarial personalizada en la que se basa tu aplicación para satisfacer sus necesidades. Además, el código de webhook también puede contener controladores de intents.

Para mejorar el nivel de detalle de las pruebas de unidades del código de entrega, te recomendamos organizar el código de tal manera que la lógica empresarial quede separada de las rutinas de control de intents. Esto significa tener controladores de intents y lógica empresarial en módulos separados, para que cada pieza se pueda probar de forma independiente.

Para ver un ejemplo, consulta nuestra acción de ejemplo de shiritori en GitHub. En esa muestra, functions/index.js y functions/shiritori/*.js contienen, por separado, los controladores de intents y la lógica empresarial, lo que permite conjuntos de pruebas más sólidos.

Pruebas de integración

Para escribir casos de prueba que abarquen la integración entre Dialogflow y tu código de webhook de entregas, lee la sección de pruebas de integración para Dialogflow que aparece más arriba.

Pruebas de carga

Antes de implementar tu acción en producción, también recomendamos realizar pruebas de carga de la entrega de webhooks para detectar problemas de rendimiento que causan degradación o interrupción del servicio de entrega.

Estos son algunos ejemplos de problemas de rendimiento que puedes detectar en las pruebas de carga:

  • Procesamiento y memoria limitados
  • Restricciones de cuotas de tus proveedores
  • Lecturas y escrituras de datos lentas
  • Problemas de simultaneidad en el código

Las situaciones de prueba de carga dependen del patrón de uso esperado o histórico de tu Acción, pero las situaciones típicas para probar son los aumentos repentinos en la carga (aumento repentino) y las cargas sostenidas (en absoluto).

Identifica situaciones en las que se llama a tu webhook y este realiza operaciones que requieren muchos recursos. Las operaciones típicas que consumen muchos recursos incluyen consultar una base de datos, llamar a otra API y realizar operaciones de procesamiento y de memoria, como renderizar un archivo de sonido.

Para estas situaciones, puedes capturar solicitudes enviadas por los servidores de Actions on Google al webhook desde tus registros de webhook o desde los registros de Stackdriver. También puedes capturar solicitudes desde el simulador de la Consola de Actions.

Una vez que tengas las solicitudes, puedes usar una herramienta de prueba de carga para descubrir cómo responde el webhook en diferentes situaciones de prueba de carga. En las siguientes subsecciones, se proporcionan algunos ejemplos de pruebas de aumento de actividad y de prueba de inmersión mediante ApacheBench.

Pruebas de aumentos repentinos

Las pruebas de aumentos repentinos requieren que envíes una cantidad constante de solicitudes al webhook durante un tiempo y que aumentes la carga de forma repentina. Por ejemplo, puedes configurar una prueba que envíe una carga de 10 consultas por segundo (QPS) con algunos aumentos de 60 QPS.

Puedes ejecutar el siguiente comando de ApacheBench para enviar 60 solicitudes simultáneas a tu webhook:

ab -n 60 -c 60 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName

Supongamos que el archivo ActionRequest.json contiene la carga útil de la solicitud capturada que se envió a tu webhook.

Pruebas de inmersión

Las pruebas de inmersión requieren que envíes una cantidad constante de solicitudes al webhook y observes la respuesta. Por ejemplo, puedes configurar una prueba que envíe una carga constante de 10 a 20 QPS durante varios minutos para ver si aumentan los tiempos de respuesta.

Puedes ejecutar el siguiente comando de ApacheBench para enviar 1,200 solicitudes, con 10 solicitudes simultáneas por segundo:

ab -t 120 -n 1200 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName

Supongamos que el archivo ActionRequest.json contiene la carga útil de la solicitud capturada que se envió a tu webhook.

Analiza los resultados de las pruebas de carga

Después de ejecutar pruebas de carga, analiza los resultados de los tiempos de respuesta de webhook. Los indicadores de problemas en la implementación del webhook suelen ser tendencias, como un tiempo de respuesta medio que aumenta con cada ejecución de prueba o un tiempo de respuesta en el peor de los casos inaceptable para tu Acción.

Pruebas de extremo a extremo

Las pruebas de extremo a extremo antes de enviar la Acción para su aprobación usan el simulador de la Consola de Actions. Puedes encontrar los pasos para realizar pruebas de extremo a extremo en el simulador de la Consola de Actions en la documentación del simulador de acciones. Realizar estas pruebas te ayuda a quitar las posibles incertidumbres del componente de infraestructura de Actions on Google.