El código bajo prueba es un desarrollo artificial para el TP

[evolentini]

La consigna pedía explícitamente probar una porción de código real, el código bajo prueba no es código real de un embebido (tiene numerosos printf) y fue desarrollado específicamente para el TP, pero sin usar TDD con requisitos claros (que hubiera sido una opción válida). La complejidad del código utilizado y de las pruebas efectuadas no es suficiente para cumplir los requerimientos mínimos del trabajo práctico.

@marianofino @rafaeloliva

[Scicchitano]

Esteban, el código testeado son distintos trozos de código de mi proyecto final de la CESE. No logro entender que es lo que te hace suponer que no lo es. Es un código que tiene mucha funcionalidades, pero la principal es detectar el paso de personas y alertar cuando una persona ingresa sin autenticarse. Si el problema esta en los printf, lo hice porque mi proyecto final esta hecho sobre un ESP32 y la manera en la que se puede escribir mensajes en el mismo es con la funcion ESP_LOG(), pero si yo en el TP lo dejo tal cual como se usa en el ESP32, no me va a funcionar, por eso lo cambie por printf.

Te pido que me aclares esto para ver como avanzar o cambiar el código bajo prueba porque no estaría entendiendo cual es el problema.

[Scicchitano]

A continuacion detallo el objetivo de cada funcion testeada:

Check_Puerta: El equipo dispara una alarma cada vez que la puerta queda abierta por un tiempo mayor al especificado por el usuario, entonces le paso como argumento la ultima vez que se detecto la puerta abierta y hace la comparacion con la hora actual para ver si hay que disparar la alarma.

Check_Reset_Modem: El ESP32 tiene un modem conectado, el mismo suele dejar de funcionar cada 2 o 3 dias y es necesario reiniciarlo para que vuelva a emitir wifi, entonces se reinicia a traves de un rele durante el horario no operativo (tipicamente a la madrugada) . De esta manera, nunca deja de funcionar.

Check_TAG: El equipo tiene un lector RFID que identifica etiquetas que se pegan a objetos valiosos (notebook, discos duros, etc) y envia por I2C el TAG. Hay TAGs que estan habilitados para salir del edificio y otros que no. Entonces la funcion lo que haces es validar si el TAG leido esta dentro del vector de TAGs validos para salir.

add_intruso: Cada vez que se detecta un intruso, el sistema lo envia por mail, pero cuando no tiene internet por cualquier motivo, el sistema guarda en un vector, el horario en el que se detecto y los encola para enviarlos cuando recupera conexión.

send_intruso: Cuando se recupera la conexion, se envian los intrusos pendientes que se encolaron en la función add_intruso(). Aca lo que si cambie es que, la funcion send() en realidad lo que hace es enviar el mail, lo que pasa es que en el codigo real, se utiliza una libreria que hace un request a un servidor SMTP, pero esa libreria solo esta adaptada para el ESP32, por lo cual, si la pego exactamente igual en el TP, no va a funcionar.

[evolentini]

Diego, te acepto que el código no haya sido escrito a medida, pero el código bajo prueba tiene severos problemas de diseño. Por ejemplo, en el caso de los TAGs, la lista de tags validos esta en RAM (la variable no esta marcada como CONST) pero no se puede modificar, y claramente los valores asignados no son valores reales de TAGs. El diseño actual implica que para cambiar un TAG hay que recopilar el código y volver a grabar el micro. Ademas las funciones para gestionar no deberían estar en la misma biblioteca que las funciones para controlar el modem o para gestionar los TAGs autorizados.

De mi observación original mantengo el hecho de que el código bajo prueba no tiene complejidad, lo mas complejo que hay en las funciones bajo prueba es un for para recorrer un vector. Y el el problema de fondo en esta cuestión es que el código esta mal diseñado, las funciones tienen muy poca responsabilidad.

En el caso del envío de los intrusos lo razonable sería que el vector sea privado de la biblioteca, la función add_intruso() registre los intrusos y la función send_intruso() envíe los pendientes, sin tener acceso al vector. Si en el vector se registra la fecha y hora, la función add_intruso() debería encargarse de ello y si para enviar hace falta tener conexión a Internet la función send_intruso() debería encargarse de ello. Finalmente, se debe reemplazar las funciones del ESP32 que utilizan el SMTP por un mock, justamente para poder hacer las pruebas sin hacer cambios en el código.

Mi sugerencia es que busques un código más complejo, pero podrías mejorando la funcionalidad de este par de funciones podrías cubrir los requerimientos mínimos del práctico. Desde ya estoy a tu disposición para ayudarte a reformar el código o a elegir otro código para no tener dos veces el mismo problema.

@marianofino @rafaeloliva