Ofertas en tecnología

Test-Driven Development o Thor-Driven Development: esa es la cuestión

Test-Driven Development (TDD) o Test-Driven Development pertence a las prácticas mucho más conocidas y admiradas de la metodología ágil de avance de programa llamada Programación Extrema (XP).

Es una técnica usada para asegurar la calidad y reducir el peligro de defectos de incrustación o insectos en el producto

Esta técnica se compone de cinco pasos:

  1. Escriba la prueba antes de redactar el código: Investigar, detectar y documentar las pruebas que tienen que efectuarse;
  2. Mande la prueba, que debería fallar: Ya que el código no fué creado, la prueba fallará y el creador va a tener la seguridad de que ningún otro código pasa la prueba. Si la prueba pasa, quiere decir que ahora hay un código creado que aborda la situación a evaluar;
  3. Redacta el código: Escriba el código preciso para llevar a cabo pasar la prueba;
  4. Vuelva a mandar la prueba, que debería pasar: Si la prueba pasa tras el nuevo código, tiene la seguridad de que pasó la prueba gracias a su código. Si la prueba no pasa, debe regresar al paso previo y corregir el código;
  5. Refactorizar el código: Realizar el código mucho más muy elegante, descartando redundancias y facilitando su cuidado.

Estos pasos asimismo se conocen como Colorado (prueba errada), Verde (prueba aprobada) y limpio (código de refactorización).

“Pero Vitor, ¿cuáles son las virtudes de utilizar esta técnica? ¡Como creador voy a tener mucho más trabajo! ¿Por qué razón redactar y realizar una prueba primero si ahora sé que fallará?”.

Hayamos ido a las ventajas:

  • Evite las pruebas «amañadas»;
  • Garantiza que el acontecimiento que ocurrió entre el fracaso y el éxito de la prueba, el avance del código, fue verdaderamente responsable del éxito de la prueba;
  • Garantiza que el código se probará y refactorizará conforme se lleva a cabo;
  • Si la prueba ahora funcionó antes que el código, esto quiere decir que la ocupación ahora existe y no se va a escribir código insignificante y duplicado;
  • Evite el fluído de ida y vuelta entre el equipo de avance y el cliente o entre el equipo de avance y el equipo de prueba/control de calidad gracias a fallos en el código.

Ahora participé de una experiencia donde un Equipo de Avance se encontraba tan maduro en la utilización del avance pensado para pruebas, que no era precisa la presencia del área de pruebas a lo largo del emprendimiento, como todas y cada una de las entregas efectuadas por el Equipo de Avance sencillamente no tenía defectos. .

Ahora, se expone un caso de muestra del empleo del avance apoyado en pruebas:

FUNCTION VALIDA_REGRAS_NEGOCIO RETURN BOOLEAN IS
BEGIN
   RETURN(FALSE);
END;

La prueba del procedimiento previo fallará pues la devolución es falsa. El próximo paso es redactar el código esperado.

FUNCTION VALIDA_REGRAS_NEGOCIO RETURN BOOLEAN IS
BEGIN
  …. Regra de Negócio 1
  ….
  RETURN(TRUE);
EXCEPTION – Em caso de erro regresa falha
  WHEN OTHERS THEN
    RETURN(FALSE);
END;

Al realizar una exclusiva prueba, si la prueba pasa (retorno verdadero) era visible que el código creado era el responsable del éxito de la prueba. Si la prueba falla, va a deber comprobar el código hasta el momento en que pase la prueba.

En este momento agreguemos una segunda regla comercial al código.

FUNCTION VALIDA_REGRAS_NEGOCIO RETURN BOOLEAN IS
BEGIN
  …. Regra de Negócio 1
  ….
  …. Regra de Negócio 2
  ….
  RETURN(TRUE);
EXCEPTION – Em caso de erro regresa falha
  WHEN OTHERS THEN
   RETURN(FALSE);
END;

Si la prueba comienza a fallar (falso retorno) es obvio que el código que se refiere a la segunda regla de negocio cambió el accionar de la prueba que había tenido éxito en el paso previo.

Si deseas reforzar en la utilización del avance apoyado en pruebas, te invito a leer el libro TDD: avance apoyado en pruebas por Kent Beck, constructor de la técnica.

Esta es una técnica mucho más a fin de que evites emplear la otra práctica TDD generalmente usada en el planeta del programa y que yo llamo Avance impulsado por Thor.

“Pero Víctor, ¿qué sería Thor? ¿Es alguna técnica novedosa?

¡No, viene de Thor, el dios del trueno de los cómics de Marvel! Es un avance pensado para “martillar”, parches, código malo, código mal probado, código que “está ya listo, pero solo precisa ser probado”, fallos.

¡Abajo la deuda técnica, hacia el avance de programa de calidad!

¡Un abrazo y nos observamos en el próximo producto!

Tommy Banks
Estaremos encantados de escuchar lo que piensas

Deje una respuesta

TecnoBreak | Ofertas y Reviews
Logo
Enable registration in settings - general
Shopping cart