Muchos desarrolladores tenemos este proyecto personal con el cual aspiramos en algún momento tener un ingreso extra, ayudar a nuestra comunidad, hacernos millonarios o simplemente aprender una nueva tecnología.
Pero además de esto, todos tenemos nuestras obligaciones con el trabajo, nuestra familia, hijos, etc. Por lo cual estos proyectos personales suelen quedar relegados a una hora por las noches o a los fines de semana, y es lo primero que hacemos a un lado cuando nuestras responsabilidades se complican (o nos invitan a la playa el fin de semana).
Esto pasó con la plataforma de Styde en Laravel (sí, muchas veces nuestros side projects tienen sus propios side projects). Yo comencé a desarrollarla a mediados del año pasado, pero la necesidad de crear nuevos cursos + mi viaje a Londres + la situación venezolana + atender clientes, dejó el proyecto a un lado por varios meses. Sumado a esto, a mitad de desarrollo pensé que necesitaba desarrollar un par de componentes que le hacían falta al proyecto; así terminó la mitad del código como parte del proyecto, una cuarta parte como un componente A (que pasó a ser Styde\Html) y la otra cuarta parte como un componente B que nunca terminé.
La información sobre el progreso del proyecto y del desarrollo de los componentes solo la tenía en mi mente; cuando trabajaba a diario este pequeño detalle carecía de importancia, pero cuando pasé 3 meses sin tocar el proyecto ¡PUF! Toda esa información se esfumó: no tenía idea de cuánto progreso llevaba, de qué hacía falta, de porqué declaré esta clase y no otra, menos aún de qué estaba funcionando y que no. Al abrir la página en el navegador y recibir el primer error, entré en pánico y no volví a tocar el proyecto nunca más.
¿Te suena parecida esta historia? Por supuesto que sí.
Escribiendo pruebas unitarias
Actualmente me encuentro desarrollando un proyecto completamente secreto con Laravel… ¡OK! Es la plataforma de Styde (intento número 2) y lo primero que hice antes de comenzar el proyecto fue… Instalar Laravel, por supuesto, pero lo segundo que hice fue generar la primera prueba y partir de allí. Ahora todo está probado, hasta las partes más sencillas del proyecto como el sistema de votos y de comentarios tienen varias pruebas de integración y de aplicación de todos los posibles escenarios (si el usuario vota 1 vez, si intenta votar 2 veces por el mismo post, si vota y luego elimina el voto, etc.) Así que cuando estoy complicado con la grabación de nuevos cursos (o tratando de conocer todos los museos y parques de Londres) y pasan varias semanas antes de que retome el proyecto, las carpetas y archivos en el directorio tests me indican exactamente el progreso que llevo, ejecutar las pruebas me indica qué dejé funcionando, que no y porqué, y el código de las pruebas en sí me sirve de documentación de los features del proyecto y me permite recordar porqué creé esta clase y no otra, etcétera, etc.
Por supuesto esto aplica para proyectos personales o comerciales que tendrás que mantener durante varios meses o años. Mas aún si tienes que trabajar en equipo, porque si tú en 3 meses no tendrás idea de qué estabas programando, imagínate el pobre colega que tendrá que asimilar toda tu lógica de golpe y no va a tener ningún tipo de apoyo. Seguramente a ti te parece perfecta la manera cómo desarrollaste la aplicación, pero sin pruebas, él no va a entender cuán genial eres y te regresará el favor llenando de parches toda la app. Yo lo llamo karma.
Nosotros en Styde y yo personalmente hablo muchísimo sobre las pruebas automatizadas y su importancia, sobretodo porque como tú, yo también desarrollaba sin usarlas -aún después de saber que existían- pero ahora simplemente no puedo trabajar sin ellas.
Mantente enfocado
Otro beneficio gigante de escribir pruebas para tus proyectos es que te permiten mantenerte enfocado en metas a corto, mediano y largo plazo; como por ejemplo finalizar un feature o un módulo. Mientras que sin pruebas es muy fácil comenzar a programar el módulo de posts y terminar creando un paquete para Laravel o rediseñando la página, al escribir una prueba, por ejemplo test_a_user_can_write_comments, tu meta inmediata es permitir que un usuario pueda escribir comentarios, nada más. Yo suelo colocarme desafíos como éste cada vez que retomo el proyecto y esto me permite avanzar poco a poco pero con pasos seguros.
Aprende a escribir pruebas unitarias
Si quieres dar un primer vistazo a cómo es desarrollar con pruebas automatizadas, puedes ver la lección 2 de nuestro curso Primeros Pasos con Laravel, la cuál es totalmente gratuita.
Si buscas un curso “puntual” de pruebas unitarias y Test Driven Development en Styde, no vas a encontrarlo, y esto es porque las pruebas no son un tema “aislado” sino que son parte fundamental del desarrollo y por ello todos nuestros cursos incluyen secciones y ejercicios basados en pruebas (TDD).
Así que si tienes un nivel básico, comienza con ese video que te explica mi Flujo de Desarrollo con Laravel, y si tienes un nivel avanzado puedes ver nuestro curso de creación de Componentes para PHP donde además de TDD y PHPUnit aprenderás conceptos más avanzados como uso de Interfaces, Stubs, Mocks, inyección de dependencias, etc.
De cualquier forma, sea cual sea tu nivel, comienza a aprender a escribir pruebas hoy mismo y estoy seguro que tal como sucedió conmigo, no sólo te hará más productivo y te permitirá desarrollar proyectos personales y mantener proyectos comerciales de forma más fácil, además nunca volverás a querer trabajar sin ellas.
Material relacionado
- Cómo escribir pruebas unitarias y de aplicación y diferencias
- Introducción a las pruebas de aplicación
- Introducción al diseño de clases con pruebas unitarias en PHPUnit
Regístrate hoy en Styde y obtén acceso a todo nuestro contenido.
