Una guía práctica a las pruebas.
Uno de los temas más importantes en el desarrollo de software es generar programas que nunca fallen. Hay muchas formas de lograr esto si estás dispuesto a invertir tiempo, dinero y a sacrificar la agilidad de tu equipo con proceso y reglas; si eres serio y sabes que tienes que balancear calidad de código con deadlines cambiantes necesitas algo mejor: prepárate para cambiar tu vida porque hay un secreto para dejar de tener bugs para siempre: Pruebas.
OK, tal vez estás pensando: “las pruebas existen desde hace muchos años y no han solucionado el problema”, tienes un buen punto. No es solamente las pruebas, es una nueva aplicación que se llama TDD! TDD corre en todos los lenguajes y significa “Tests, Definitely Do!” que es una frase en inglés que significa “Pruebas, definitivamente hazlas!” (PDH por sus siglas en español). El PDH consiste en una regla sencilla: Escribe tu prueba primero, luego escribe el codigo que pase la prueba. Suena fácil, pero no es tan fácil porque es difícil. Tus pruebas deben probar lo que hace tu programa y no como está implementado. Esto es lo más importante de PDH y es lo que viene a cambiar las formas en las que hacíamos pruebas.
Por ejemplo: digamos que tenemos un sistema de control de veneno de ornitorrinco. Los clientes dirán: “Necesitamos un sistema de control de veneno de ornitorrincos que funcione en tabletas y celulares para que nuestros recolectores de veneno de ornitorrinco puedan saber cuanto hay y cuanto les falta”. En ese caso, si seguimos PDH terminaríamos con las siguientes pruebas:
(Nota, utilizare un pseudo código para explicar las pruebas, donde cada una DESCRIBE alguna serie de objetos que DEBERÍAN pasa)
DESCRIBE el sistema de ornitorrincos
DEBERÍA funcionar
DEBERÍA funcionar en el celular y tabletas
El cuerpo de cada bloque de DEBERÍA es una prueba, ahí debemos escribir el código. Esto depende de que tipo de prueba estás haciendo (hay pruebas unitarias, pruebas de opción multiple, pruebas de integración y pruebas estandarizadas.) El cuerpo final obviamente dependerá de la implementación del software que se está probando: El secreto es que la prueba se queda igual, aún es DEBERÍA funcionar, solo la cambiamos por dentro. Ese es el secreto de una buena prueba: Amplia para que no cambie seguido.
¡Listo! Eso fue fácil. Pudimos extraer los requerimientos del cliente y convertirlos en pruebas. El código está 100% cubierto, este es un termino de PDH y se le llama cobertura cuando las pruebas cubren todos los casos: entre más casos cubra una sola prueba es señal de que estás probando resultado y no implementación. Hay que tratar de llegar a 100% cobertura cada vez (si son más de dos pruebas puede que no estés generalizando lo suficiente.) Esto se puede lograr con sistemas de CI (Cobertura Instantanea) como Travis CI o CNCI. Estos son sistemas que se encargan de tener a alguien constantemente diciendote como generalizar tus pruebas. Si tus pruebas no pasan significa que necesitas generalizarlas más.
Ahí lo tienen! Reglas sencillas para tener pruebas y producir consistentemente código con 100% de cobertura y 0% de bugs. ¿Empezarán a hacer sus pruebas? La discusión sigue por twitter
