TESTS

En el proyecto podemos encontrar los siguientes tests que nos ayudan a asegurar la calidad y fiabilidad del software, garantizando que cada componente funcione como se espera bajo distintas condiciones.

En dexma-connector

index.spec

Verifican la integración del módulo dexma-connector simulando respuestas de un endpoint. El primer test simula una respuesta exitosa para comprobar que el conector maneja correctamente una transacción que se completa con éxito, esperando que el objeto de respuesta context.res coincida con la respuesta simulada. El segundo test simula una respuesta fallida del servidor para probar la resiliencia del conector y la correcta gestión de errores. Finalmente, el tercer test verifica cómo el conector maneja una solicitud con un payload que carece de información de un nodo remoto, asegurándose de que el sistema sigue funcionando como se espera en casos donde algunos datos podrían estar ausentes o incompletos. En todos los casos, se establece una URL de endpoint de prueba y se espera que la respuesta coincida con la respuesta predefinida tras ejecutar la función del conector.

infrastucture/modules/requestBuilder.spec

Verifica que la función createTextPlainData del módulo requestBuilder esté formando correctamente una cadena de texto que representa datos en formato plano. Utiliza datos de prueba importados (mocks) para simular los valores de entrada y compara el resultado de la función con un valor esperado, que es un string que contiene la palabra "data=" seguida de los datos de prueba en formato JSON. El propósito del test es asegurarse de que los datos se estén construyendo de manera adecuada para su envío en solicitudes HTTP, y una afirmación fallida indicaría un defecto en la lógica de construcción de la solicitud.

infrastucture/services/restServiceBase.spec

Validan la función requestAsync para realizar solicitudes HTTP POST y manejar diferentes tipos de respuestas. Se simulan respuestas exitosas tanto en formato JSON como en texto plano, verificando que la función devuelva correctamente el contenido esperado y que la función fetchMock se llame una sola vez en cada caso. También se prueba el manejo de errores, simulando una respuesta fallida con un código de estado 500 y comprobando que la función maneje correctamente la excepción y devuelva null. Finalmente, se evalúa el comportamiento de la función cuando se proporciona un método HTTP nulo, esperando también un resultado null, asegurando que la función gestiona adecuadamente los casos anómalos de entrada.

En iot-central-bridge

aplication/services/iotcentralService.spec

Verifica que la función mappingJsonDataDevice del servicio iotcentralService procesa correctamente los datos de entrada y devuelve una lista de dispositivos con sus datos mapeados (dataDeviceList). El test comienza con la creación de un contexto de prueba y un objeto JSON que representa los datos de los dispositivos (con campos como identificador, marca de tiempo y registros de diferentes medidas). Luego, invoca la función mappingJsonDataDevice con estos datos y verifica que el resultado no sea nulo y que la longitud de la lista de dispositivos mapeados sea mayor que cero, confirmando que la función es capaz de interpretar y transformar los datos de entrada en una estructura de datos adecuada para su uso posterior en la aplicación.

En shared

domain/modules/parserEngine.spec

Evalúan distintas funciones de parserEngine, un módulo destinado a interpretar y transformar datos de un formato específico. El primer test verifica que processFieldInfo analice correctamente una cadena de texto representando información de campo y devuelva un objeto con detalles como el tipo de maestro, tipo de mensaje y errores específicos, así como el tipo y el ID del nodo remoto. El segundo test se enfoca en processFieldEnergy, asegurándose de que la función procese una cadena que representa datos de energía y devuelva un objeto con la energía activa y reactiva calculada. El tercer test comprueba processFieldRemoteNode, esperando que la función tome el ID de un nodo remoto y una cadena de bytes para ese nodo, y retorne un objeto con el ID del nodo, el ID del servicio y el conteo correspondiente. En todos los casos, se espera que las funciones procesen y mapeen correctamente los datos de entrada a una estructura definida esperada para su posterior uso en el sistema.

domain/services/payloadProcessorService.spec

Validan la capacidad para procesar correctamente varios tipos de cargas útiles provenientes de dispositivos IoT, traduciéndolas en objetos estructurados según las expectativas. Estos tests cubren una amplia gama de escenarios, desde el procesamiento estándar de payloads hasta la interpretación precisa de datos específicos de dispositivos de temperatura, humedad, CO2, y contadores de pulsos, trabajando con redes como LongNet 868. Se enfocan en confirmar que el servicio puede extraer información clave como el tipo de dispositivo, convertir cargas útiles en formatos de datos esperados, y manejar casos especializados, asegurando una conversión fiel y eficaz que soporta el análisis y gestión posterior de los datos recogidos.