Las pruebas son una parte importante del desarrollo de software. Seamos conscientes
de ello o no, ralizamos pruebas contínuamente.
Por ejemplo, cuando escribimos una clase en PHP, podemos depurarla paso a paso o
simplemente usar declaraciones echo
o die
para verificar que la implementación
funciona conforme a nuestro plan inicial. En el caso de una aplicación web, introducimos
algunos datos de prueba en los formularios para asegurarnos de que la página interactúa
con nosotros como esperábamos.
El proceso de testeo se puede automatizar para que cada vez que necesitemos verificar algo, solamente necesitemos invocar el código que lo hace por nosotros. El código que verifica que el restulado coincide con lo que habíamos planeado se llama test y el proceso de su creación y posterior ejecución es conocido como testeo automatizado, que es el principal tema de estos capítulos sobre testeo.
El Desarrollo Dirigido por Pruebas (Test-Driven Development o TDD) y el Desarrollo Dirigido por Corpotamientos (Behavior-Driven Development o BDD) son enfoques para desarrollar software, en los que se describe el comportamiento de un trozo de código o de toda la funcionalidad como un conjunto de escenarios o pruebas antes de escribir el código real y sólo entonces crear la implementación que permite pasar esos tests verificando que se ha logrado el comportamiento pretendido.
El proceso de desarrollo de una funcionalidad es el siguiente:
Una vez hecho, se repite el proceso de neuvo para otra funcionalidad o mejora. Si se va a cambiar la funcionalidad existente, también hay que cambiar los tests.
Consejo: Si siente que está perdiendo tiempo haciendo un montón de iteraciones pequeñas y simples, intente cubrir más por cada escenario de test, de modo que haga más cosas antes de ejecutar los tests de nuevo. Si está depurando demasiado, intente hacer lo contrario.
La razón para crear los tests antes de hacer ninguna implementación es que eso nos permite centrarnos en lo que queremos alcanzar y sumergirnos totalmente en «cómo hacerlo» después. Normalmente conduce a mejores abstracciones y a un más fácil mantenimiento de los tests cuando toque hacer ajustes a las funcionalidades o componentes menos acoplados.
Para resumir, las ventajas de este enfoque son las siguientes:
A largo plazo normalmente tiene como efecto un buen ahorro de tiempo.
Aunque el enfoque de primero los tests descrito arriba tiene sentido para el largo plazo y proyectos relativamente complejos, sería excesivo para proyectos más simples. Hay algunas indicaciones de cuándo es apropiado:
No hay nada malo en crear tests que cubran el comportamiento de una implementación existente.
En algunos casos cualquier forma de testo automatizado sería exagerada:
De todas formas, si dispone de tiempo, es bueno automatizar las pruebas también en esos casos.
Found a typo or you think this page needs improvement?
Edit it on github !
Signup or Login in order to comment.