Pruebas de conectores
Comando test
El comando test se utiliza para probar los elementos de conector. Los elementos tienen algunas opciones comunes y algunas específicas. El comando test toma el tipo del elemento como subcomando. El comando test tiene los siguientes comandos:
Comandos | Descripción |
|---|---|
flow test action <name> | Permite probar la acción denominada <name>. |
flow test connection <name> | Permite probar la conexión denominada <name>. |
flow test lookup <name> <method> | Permite probar la función de búsqueda denominada <method> en la búsqueda <name>. |
flow test oauth <name> | Permite probar la instancia de OAuth denominada <name>. |
flow test trigger <name> <method> | Permite probar el activador denominado <name>. |
El comando test tiene las siguientes opciones:
Opciones | Descripción | Tipo de datos |
|---|---|---|
--version | Permite mostrar el número de versión. | [booleano] |
--help | Permite mostrar la ayuda. | [booleano] |
--timeout | El tiempo de espera de la operación. La opción --timeout permite especificar un tiempo de espera en milisegundos (30.000 ms por defecto). Esta opción garantiza que el código finalizará dentro del tiempo especificado y que capturará los errores, como la omisión de invocación de llamadas. | [por defecto: 30000] |
--logLevel,-1 | Permite definir el nivel de registro. | [por defecto: "info"] |
La CLI de ThingWorx Flow permite probar elementos individuales antes de implementar el conector en el servidor. De este modo, se puede comprobar si los elementos funcionan correctamente antes de implementar el conector.
Los casos de prueba se escriben empleando el marco mocha-chai. Mocha se utiliza para definir el conjunto de pruebas y chai se utiliza como biblioteca de condiciones. Todos los casos de prueba se definen en la carpeta testData, en una carpeta determinada de prueba de elementos.
El comando test permite realizar pruebas de elementos en la CLI de ThingWorx Flow.
Para probar un elemento, ejecute los siguientes comandos desde el símbolo del sistema:
1. cd <user project root directory>
2. flow test <artifactType> <name>
Configuración para pruebas de OAuths y activadores
Los comandos flow test oauth y flow test trigger inician internamente un servidor Web. El servidor Web solo acepta solicitudes https. Para permitir que atienda solicitudes de configuración, se necesitan certificados. Si faltan certificados, se produce el siguiente error:
[2018-09-19T10:13:11.876] [ERROR] trigger - Validation of trigger failed : ENOENT: no such file or directory, open 'C:\[2018-09-19T10:13:11.876] [ERROR] trigger - Validation of trigger failed : ENOENT: no such file or directory, open 'C:\<user-home-dir\.flow\key.pem>
Para crear un certificado autofirmado, realice lo siguiente:
1. Descargue e instale openssl.
2. Suponiendo que openssl se encuentre en la ruta, ejecute openssl req -nodes -new -x509 -keyout key.pem -out cert.pem
3. Copie estos ficheros en el directorio .flow del directorio inicial del usuario.
Para configurar el nombre de host y el puerto, cree un fichero flow.json, en el directorio .flow del directorio inicial de los usuarios. A continuación, se incluye un fichero de ejemplo:
{
"passphrase": "xyz",
"hostname" : "flow.local.rnd.ptc.com",
"port" : 443
}
"passphrase": "xyz",
"hostname" : "flow.local.rnd.ptc.com",
"port" : 443
}
Todas las propiedades son opcionales.
• Passphrase: se utiliza con la clave privada que requiere una frase de contraseña.
• Hostname: se utiliza para construir redirect_uri para OAuth y para crear los URL de activador. Es posible que muchos servicios no permitan localhost como nombre de host válido en redirect_uri. Algunas aplicaciones requieren específicamente URL que no sean localhost, como los URL de registro de webhook. También se puede intentar hacer coincidir el URL para el sistema de desarrollo con el sistema de producción para la prueba. Por ejemplo, si el elemento redirect_uri que se ha registrado con Google es https://flow.local.rnd.ptc.com/Thingworx/Oauths/oauth/return, el nombre de host de flow.json debe ser flow.local.rnd.ptc.com. Además, se debe añadir el host a <%WINDIR%>\system32\drivers\etc\hosts.
 | Para editar el fichero, ejecute el editor como administrador. |
Pruebas de una configuración de OAuth
Las pruebas de configuración de OAuth se realizan mediante un explorador puesto que cada proveedor de OAuth tiene un formulario diferente para aceptar las credenciales de usuario. La CLI ejecuta internamente un servidor Web exprés para procesar las respuestas que se envían desde IdP en la autenticación correcta o incorrecta.
Para probar una configuración de Oauth, realice lo siguiente:
1. Desde el directorio de proyecto, ejecute el siguiente comando:
flow test oauth <oauth name>
Después de conectarse correctamente, se abre la ventana del explorador del validador de OAuth. Para obtener más información, consulte el ejemplo del tutorial.
2. Seleccione la configuración que se debe probar y, a continuación, pulse en la opción para validar la configuración de OAuth o pulse en el botón Salir.
Pruebas de una conexión
El comando test connection llama al método validate. A continuación, llama al método connect, prueba la entrada con el esquema de entrada y prueba la salida con el esquema de salida.
Para probar una conexión, realice lo siguiente:
1. Desde el directorio de proyecto, ejecute el siguiente comando:
npm install
2. Cree un fichero de datos de prueba en el paquete y rellene sus datos con la información del proveedor de servicio.
En el fichero se incluyen datos de ejemplo para la prueba connectionTestData en <dirProyecto>\test\testData tal como se muestra en el siguiente código.
module.exports = {
sampleInput : {
email : 'your-email-id-here',
subscription_id:'your-subscription-id',
account_url: 'your-account-url',
token: 'your-token'
},
sampleOutput : {
handle: {
email : 'your-email-id-here',
subscription_id:'your-subscription-id',
account_url: 'your-account-url',
token: 'your-token'
} }
}
sampleInput : {
email : 'your-email-id-here',
subscription_id:'your-subscription-id',
account_url: 'your-account-url',
token: 'your-token'
},
sampleOutput : {
handle: {
email : 'your-email-id-here',
subscription_id:'your-subscription-id',
account_url: 'your-account-url',
token: 'your-token'
} }
}
3. Ejecute el comando test con las siguientes opciones:
Opciones | Descripción | Tipo de datos |
|---|---|---|
--version | Permite mostrar el número de versión. | [booleano] |
--help | Permite mostrar la ayuda. | [booleano] |
--timeout | El tiempo de espera de la operación. La opción --timeout permite especificar un tiempo de espera en milisegundos (30.000 ms por defecto). Esta opción garantiza que el código finalizará dentro del tiempo especificado y que capturará los errores, como la omisión de invocación de llamadas. | [por defecto: 30000] |
--logLevel,-1 | Permite definir el nivel de registro. | [por defecto: "info"] |
--artifactVersion,-v | Versión del elemento que se debe probar. | N/D |
--projectDir,-d | El directorio padre del proyecto. | N/D |
--input,-i | Nombre de la variable de entrada. | N/D |
--output,-o | Nombre de la variable de salida esperada. | N/D |
--testDataFile,-f | Ruta del fichero testData. | N/D |
--save,-s | Permite guardar en el almacén de credenciales de un usuario. | N/D |
--noSchemaValidation,-n | Permite desactivar la validación de esquema. | [por defecto: falso] |
La ejecución de test genera salida si ambos métodos, connect y validate, se ejecutan correctamente. El comando también verifica que la entrada coincida con el esquema de entrada y la salida con la salida esperada.
La opción --save almacena la salida del comando connect en el fichero creds.json de la carpeta .flow del directorio inicial de los usuarios. La salida de la ejecución de este comando es la clave en la que se almacena la conexión en el fichero. Esta clave más tarde se puede utilizar para transmitir la información de autenticación almacenada a otro comando test.
Pruebas de búsquedas
Las búsquedas tienen una estructura distinta a otros elementos y su versión no se genera de la misma manera que para otros elementos. El propio nombre sirve de versión. Si se requiere una funcionalidad más reciente, se crea una nueva búsqueda con un nuevo nombre en el fichero JavasSript de búsqueda. Ejecute el comando test para las búsquedas con el siguiente comando:
Están disponibles las siguientes opciones:
Opciones | Descripción | Tipo de datos |
|---|---|---|
--version | Permite mostrar el número de versión. | [booleano] |
--help | Permite mostrar la ayuda. | [booleano] |
--timeout | El tiempo de espera de la operación. La opción --timeout permite especificar un tiempo de espera en milisegundos (30.000 ms por defecto). Esta opción garantiza que el código finalizará dentro del tiempo especificado y que capturará los errores, como la omisión de invocación de llamadas. | [por defecto: 30000] |
--logLevel,-1 | Permite definir el nivel de registro. | [por defecto: "info"] |
--projectDir,-d | El directorio padre del proyecto. | N/D |
--connection,-c | El UID de la conexión que se va a inyectar. | N/D |
--access_token,-a | Nombre de la variable de salida esperada. | N/D |
--input,-i | Ruta del fichero testData. | N/D |
--output,-o | Nombre de la variable de salida esperada. | N/D |
--testDataFile,-f | Ruta del fichero testData. | N/D |
--searchById | El ID que se utilizará para la búsqueda. | N/D |
--searchByValue | El valor que se utilizará para la búsqueda. | N/D |
--filter | El filtro que se utilizará para buscar elementos. | N/D |
flow test lookup <name> <method>
Las búsquedas tienen dos opciones de búsqueda, searchById y searchByValue, y las tres opciones siguientes con respecto a la paginación.
• La búsqueda devuelve todos los datos a la vez: no se requiere ninguna acción para esta opción.
• La aplicación soporta la API de paginación: el código de búsqueda llama a la API getNextPage y pasa los argumentos que pueden ayudar al servicio a devolver los datos de la página siguiente. Esta información se pasa a la búsqueda cuando el usuario pulsa en la opción Cargar más en la lista de valores de campo de búsqueda.
• Paginación no soportada: la aplicación consulta los datos y el servicio de búsqueda trunca los datos para mostrar solo los registros de la página actual y todas las páginas anteriores.
Pruebas de acciones
Las pruebas de acciones son similares a las pruebas de búsquedas. Las búsquedas no se prueban como parte de la acción de prueba. La entrada ya debe contener los resultados proporcionados por las búsquedas.
Para probar una acción, realice lo siguiente:
1. Escriba una entrada de ejemplo y una salida de ejemplo JSON en un fichero de datos de prueba. Para obtener ejemplos de entrada y salida, consulte el Tutorial B.
2. Desde el directorio de proyecto, ejecute el comando test con las siguientes opciones:
Opciones | Descripción | Tipo de datos |
|---|---|---|
--version | Permite mostrar el número de versión. | [booleano] |
--help | Permite mostrar la ayuda. | [booleano] |
--timeout | El tiempo de espera de la operación. La opción --timeout permite especificar un tiempo de espera en milisegundos (30.000 ms por defecto). Esta opción garantiza que el código finalizará dentro del tiempo especificado y que capturará los errores, como la omisión de invocación de llamadas. | [por defecto: 30000] |
--logLevel,-1 | Permite definir el nivel de registro. | [por defecto: "info"] |
--artifactVersion,-v | Versión del elemento que se debe probar. | [por defecto: "v1"] |
--connection,-c | El UID de la conexión que se va a inyectar. | N/D |
--access_token,-a | Nombre de la variable de salida esperada. | N/D |
--projectDir,-d | El directorio padre del proyecto. | [por defecto: "."] |
--input,-i | Ruta del fichero testData. | N/D |
--output,-o | Nombre de la variable de salida esperada. | N/D |
--testDataFile,-f | Ruta del fichero testData. | N/D |
--noSchemaValidation,-n | Permite desactivar la validación de esquema. | [por defecto: falso] |
Pruebas de activadores
Las pruebas de un activador son ligeramente diferentes de las pruebas de acciones, conexiones y búsquedas. Se puede ejecutar el comando test con las siguientes opciones:
En la siguiente tabla se describen las distintas opciones disponibles para probar activadores.
Opciones | Descripción | Tipo de datos |
|---|---|---|
--version | Permite mostrar el número de versión. | [booleano] |
--help | Permite mostrar la ayuda. | [booleano] |
--timeout | El tiempo de espera de la operación. La opción --timeout permite especificar un tiempo de espera en milisegundos (30.000 ms por defecto). Esta opción garantiza que el código finalizará dentro del tiempo especificado y que capturará los errores, como la omisión de invocación de llamadas. | [por defecto: 30000] |
--logLevel,-1 | Permite definir el nivel de registro. | [por defecto: "info"] |
--artifactVersion,-v | Versión del elemento que se debe probar. | [por defecto: "v1"] |
--connection,-c | El UID de la conexión que se va a inyectar. | N/D |
--access_token,-a | Nombre de la variable de salida esperada. | N/D |
--projectDir,-d | El directorio padre del proyecto. | [por defecto: "."] |
--input,-i | Nombre de la variable de entrada. | N/D |
--output,-o | Nombre de la variable de salida esperada. | N/D |
--testDataFile,-f | Ruta del fichero testData. | N/D |
--noSchemaValidation,-n | Permite desactivar la validación de esquema. | [por defecto: falso] |
--polling,-p | Permite indicar que se trata de un activador de sondeo. | N/D |
--event,-e | El evento que se va a probar. | N/D |
--mockData,-m | El nombre de la variable que contiene el elemento mockdata para un evento. | N/D |
--interval,-t | El intervalo en segundos después del cual se debe activar. | [por defecto: 15] |
--stopAfter,-s | Número máximo de llamadas al activador. | [por defecto: 1] |
Se debe especificar qué método se desea probar. Para activadores de sondeo, los métodos son execute y activate.
Para obtener ejemplos sobre las pruebas de varios elementos, consulte el Tutorial B.