Mi primera experiencia con testing y TDD

Imagen
Tubos de ensayo de colores con flores

Recientemente en mi trabajo, me han encargado retomar el desarrollo de un prototipo de un módulo que cree hace unos meses para estabilizarlo y añadir funciones. Termine todas las mejoras y me sobraba mucho tiempo, ya que por una vez calcularon tiempo excesivo para el desarrollo, y me sobraron días enteros. A si que decidí añadir algo, que nunca antes había añadido a un módulo o aplicación web que hubiera desarrollado, testing.

Había leído mucho sobre testing y visto varios video tutoriales y un curso, pero nunca había escrito ni una sola línea de código. A pesar de que me parecía muy útil y que facilita el desarrollo a futuro además de dar una seguridad de que lo que has desarrollado, hace lo que realmente esperas que haga; como he dicho, nunca antes había escrito nada de testing.

Primera prueba con el testing:

No tenía muy claro por dónde empezar, ya que el modulo, sirve para obtener información a través de restful, de una fuente externa, y fui al módulo “examples, para ver alguna idea de que es lo que podía testear, y vi que como ejemplo de testing, estaba el acceso a unos puntos de menú y ruta para comprobar que existían.

Comencé con eso, y al verificar las rutas, se me ocurrió verificar que existieran los tipos de media que se añaden en la instalación, y después me vino la idea de testear la instalación, y básicamente me sirvió, para corregir un pequeño problema, que sabía que existía al reinstalar el modulo, pero que había ignorado, ahora con el test, me vi forzado a corregir.

El primer test unitario y probando el TDD:

Me di cuenta, que básicamente todo esto, eran test funcionales, y quería añadir por lo menos, un test unitario. Estuve repasando las clases que había, para ver si podía añadir algún test unitario para una, pero, no encontré nada que no dependiera de peticiones externas.

Entonces decidí, reescribir una parte del código, que usaba arrays para generar un string, para que utilizaran un objeto para la generación de ese string, y sustituir al enorme array y pequeña chapuza que era.

Recordé de que existía un método llamado Test Driven Development (o TDD), que básicamente, consisten en primero escribir el test haciendo que falle, y luego ir escribiendo en la clase que queremos testear el código necesario, haciendo que el test sea exitoso, y después refactorizar la clase haciendo que siga pasando los test. Es decir “Test -> Código -> Refactorizar”.

Conclusiones:

De ahora en adelante, escribiré test, no para todo, pero si para lo que me pueda parecer más útil o que necesite cierta estabilidad. Me ha gustado la experiencia, y el saber que, si modifico algo que haya sido testeado, no me hace falta probarlo manualmente, lanzo los test, y me dicen si algo ha fallado o no.

Respecto al TDD, me llamaba la atención desde la primera vez que lo vi. A pesar que pueda parecer una pérdida de tiempo primero escribir el test, y después la clase haciendo que esta dependa del test, tras esta pequeña experiencia, creo que realmente acelera el desarrollo, lo facilita muchísimo y te “fuerza” a tener claro cuál va a ser la funcionalidad de esa clase que vas a desarrollar, así que también se tendrá todo un poco más ordenado.

Cuando descubrí el TDD, se lo comenté a un par de compañeros de trabajo, y opinaron que era una pérdida de tiempo, y pero si es un método que existe, y seguro que usado por miles de personas, no creo que sea una pérdida de tiempo, además de que me ha gustado utilizarlo.

Y aquí está mi pequeña experiencia entrando al testing, me ha gustado y como ya he dicho, añade seguridad. No creo que haga en un corto plazo un artículo dedicado al testing, ya que soy novato en esto y aún tengo mucho que aprender, pero probablemente si creare un pequeño articulo para tenerlo yo como referencia.

Artículos relacionados: