ThingWorx Flow > SDK de ThingWorx Flow > Pruebas de conectores
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 correctamente antes de.
Los casos de prueba se escriben empleando el marco mocha-cha. 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>
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
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'
} }
}
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.
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.con el siguiente comando:
flow test lookup <name> <method>
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
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 o se requiere ninguna acción para esta opción.
• La API de paginación soportada por la aplicación l código de búsqueda llama a la API de getNextPage y pasa los argumentos que pueden ayudar al servicio a devolver datos de la página siguiente. Esta información se pasa a la búsqueda cuando el usuario pulsa en la opción para cargar más elemento en la lista de valores de campo de búsqueda.
• Paginación no soportadala aplicación consulta los datos y el servicio de búsqueda trunc 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.
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 Apéndice 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 .