Más y más pruebas

¿Te imaginas un modo de desarrollar software que ponga en primer lugar las pruebas antes de hacer otra cosa? Yo tampoco, pero hoy te voy a contar que hay gente que lo hace y parece ser que le va bien haciéndolo. Seamos sinceros, a primera vista esto no parece buena idea pues lo tradicional es hacer las pruebas hasta tener algo de software medianamente funcional pero hoy en día si no te actualizas lo más probable es que fracases como un buen desarrollador, así que sin más, hablemos un poco de DPP.

Esto es extremo, viejo



La práctica de primero probar antes de desarrollar es una de las principales prácticas de XP y también de la metodología Agile, no, no estamos hablando de la mejor versión de Windows sino de Extreme Programming. Quizá al principio te parezca un poco confuso el hecho de probar algo que aún no esté hecho pero bueno, esta es una manera muy simple de verlo, lo que realmente se hace es plantear y hacer las pruebas por las cuales tendrá que pasar nuestro código antes de siquiera escribir una línea, de esta manera el código desarrollado se basará en estas pruebas y buscará que funcione de la mejor manera para las mismas. Una vez que las pruebas se van pasando entonces el desarrollo comienza a ser mucho más ágil y resulta en un código bastante limpio.

¿Por qué un código más limpio? Bueno, velo de esta forma, si tu programación no avanza a menos que satisfagas una prueba en específico entonces la cantidad de errores que pasen fase con fase seguramente sera mínima. Otro beneficio que el DPP nos proporciona es un código orientado al usuario final pues, si diseñamos las pruebas pensando en cómo es que se usará nuestro software entonces estaremos en la misma sintonía que un usuario común y por ende, nuestro software será más humano.

El proceso estandarizado para implementar un DPP no es tan dramático y lo único que lo diferencia del desarrollo tradicional es que las pruebas se desarrollan al principio, pero bueno, no dejes que te lo cuente yo, el proceso como tal es el siguiente:
  • Se comienza por crear una prueba en especifico para determinada funcionalidad del sistema.
  • Se escribe el código correspondiente para la funcionalidad especificada.
  • Se corre una prueba y en caso de no tener un resultado positivo entonces se procede a escribir código específico para que funcione correctamente.
  • Una vez la prueba se pasa entonces se revisa de nuevo el código para revisar si se puede crear una versión más simple del mismo.
No todo es miel sobre hojuelas

Como ya te pudiste dar cuenta esta metodología no parece tener ni un ápice de maldad e incluso la idea en teoría es bastante buena pero antes que de nuevo cambies la forma de desarrollar tus proyectos debes de tener en cuenta los siguientes puntos:
  • Está basado en pruebas: si el diseño de tu prueba no es lo suficientemente bueno o la necesidad de tu cliente no se acerca ni un poco a la idea que tuviste entonces el código producto de esa prueba será totalmente inútil, en pocas palabras, tu código será tan bueno como la prueba que diseñes.
  • Si estás diseñando interfaces gráficas ni lo pienses: las interfaces gráficas son una de las cosas que más cambian a lo largo del desarrollo de software así que crear una prueba y además escribir código cada vez que cambie la misma... Ya te imaginarás el culebrón que te espera. 
Este tipo de desarrollo como la mayoría tiene muchísimas cosas positivas pero otras no tanto, recuerda que el usarlo o no dependerá exclusivamente del software que actualmente estás desarrollando y por lo tanto recaerá en tí la responsabilidad de esta decisión. Pero si tienes algo que aceptar, es que conocer nuevos conceptos nunca está de más.  

Comentarios

Entradas populares de este blog

8 pharos

Primer uso de Google Cloud Functions

Dale justo lo que necesita