Una de las reglas de TDD es "escribir el código mínimo y necesario para hacer pasar una prueba unitaria que falla", estas líneas de código
|
if (led < 1 || led >= 17){ |
|
return NULL; |
|
} |
se pueden eliminar sin afectar ninguna prueba, y eso es porque no se respetó esta regla, se escribieron directamente sin escribir una prueba antes . Para que este código producción exista debería haber al menos una prueba mas que verifique que la función devuelve NULL (cosa que es imposible distinguir de un FALSE) cuando los argumentos son inválidos.
Por esta misma razón no creo que sea necesario reescribir todas las pruebas para logica directa y para logica inversa, es probable que con unas pocas pruebas adicionales queden cubiertos todos los casos. Eso se vería claramente si se hubiera ido construyendo en forma increméntalas como propone la metodología.
@marianofino @rafaeloliva
Una de las reglas de TDD es "escribir el código mínimo y necesario para hacer pasar una prueba unitaria que falla", estas líneas de código
Repo_B2/Testing_tp_02/leds/src/leds.c
Lines 83 to 85 in d6e2ecd
se pueden eliminar sin afectar ninguna prueba, y eso es porque no se respetó esta regla, se escribieron directamente sin escribir una prueba antes . Para que este código producción exista debería haber al menos una prueba mas que verifique que la función devuelve NULL (cosa que es imposible distinguir de un FALSE) cuando los argumentos son inválidos.
Por esta misma razón no creo que sea necesario reescribir todas las pruebas para logica directa y para logica inversa, es probable que con unas pocas pruebas adicionales queden cubiertos todos los casos. Eso se vería claramente si se hubiera ido construyendo en forma increméntalas como propone la metodología.
@marianofino @rafaeloliva