Las pruebas unitarias es una herramienta fundamental que nos ayudan a encontrar errores durante el proceso de desarrollo de software, pero entendemos ¿en qué casos se usa? ¿Quién debe realizarlo?, en este artículo te aclaramos estas y otras dudas más.
Es muy extraño encontrarse un desarrollador de software y más extraño aún encontrarse un arquitecto de software hablando de las pruebas que se le van a aplicar al software.
En general probar software es un tema que siempre se ha dejado para el final en donde por falta de tiempo termina siendo una tarea hecha a la carrera y sin mucho empeño.
Además, los desarrolladores tienden a pensar que esa tarea es de otros compañeros los cuales en el mejor de los casos son los “QA Tester (Quality Assurance)” y en el peor de los casos son los clientes del sistema.
Desde el punto de vista de la arquitectura de software, garantizar el funcionamiento correcto tanto desde el punto de vista estructural como funcional es una tarea tan importante como diseñar el software.
Los involucrados en las pruebas de software
Las pruebas funcionales están relacionadas con que el software desarrollado haga las cosas como el usuario espera y las pruebas estructurales son los unit test o pruebas unitarias.
Las pruebas funcionales por lo general las llevan a cabo QA Tester o usuarios finales que prueban y garantizan el buen funcionamiento del software.
Por otro lado, las pruebas estructurales o pruebas unitarias buscan garantizar que el sistema no se quiebra cuando recibe cambios o nuevas características; estas pruebas la realizan los desarrolladores de software.
Los desarrolladores y las pruebas unitarias
Aunque para nosotros los desarrolladores las dos formas de hacer pruebas deberían ser igual de importantes, debemos estar más involucrados en las pruebas unitarias ya que es algo que debemos de programar nosotros mismos. Estas pruebas nos van a permitir validar aspectos tales como:
- Si hago un cambio en el módulo A no voy a quebrar algo en el módulo B –> esto se da porque las pruebas unitarias se ejecutan cada vez que voy a subir el código como listo a mi repositorio de código, y si mi cambio en A va a quebrar B, las pruebas unitarias de B no serían exitosas.
- Cuando trabajo en equipo evita que yo modifique con un error un código que ya está probado y funcionando, ya que para que yo pueda subir el código al repositorio compartido tengo que ejecutar todas las pruebas unitarias tanto las mías como las de mis compañeros y si alguna falla no debo subir el código.
- Las pruebas unitarias me permiten hacer refactorización del código para permitir que mi código pueda ser más legible y más reutilizable, ya que cuando se desarrollan se observan oportunidades de mejora que no se distinguen cuando estamos desarrollando, por ejemplo el uso amplio del polimorfismo.
Al hablar de pruebas unitarias e involucrar a los desarrolladores en este tema, surgen muchos mitos y resistencia de parte de estos últimos ya que por lo general a el desarrollador no le gusta probar. Los mitos más comunes son:
- Las pruebas no las hago yo, le tocan al tester: FALSO. Desde todo punto de vista esta afirmación no tiene sentido ya que nadie más que le propio desarrollador conoce la estructura de su programa y nadie más que él sabe que se debe de probar para mantener al sistema estable y sin caídas inesperadas. Es tan importante que el desarrollador haga sus pruebas ya que con esto eliminamos en un porcentaje muy alto – depende del porcentaje de cobertura – la posibilidad de que nuestro sistema tenga caídas inesperadas no controladas. Además el construir estas pruebas le permite al desarrollador encontrar vacíos de diseño y oportunidades de mejora utilizando el refactoring, algo de lo que hablaremos en otro post.
- Si tengo que programar los unit test necesito más tiempo de desarrollo: FALSO. Esta más que demostrado que cuando uno utiliza pruebas unitarias reduce el tiempo de desarrollo de los proyectos, esto por cuanto se disminuye la mayoría del re trabajo en los proyectos de desarrollo. Por lo general el re trabajo es algo que no se toma en cuenta a la hora de hacer los planes de proyecto y al final es el rubro que se termina comiendo el cronograma y el presupuesto.
- Los unit test son difíciles de programar y llevan mucho código: FALSO. Al contrario, las pruebas unitarias para que estén bien hechas deben de ser sencillas, rápidas, y fáciles de programar. De acuerdo a Roy Osherove en su libro “El arte de las pruebas unitarias” (El cual por cierto es muy, muy recomendado leerlo), una prueba unitaria debe de ser escrita de forma tal que en 10 minutos tengamos algo para probar; y es totalmente cierto, en muy raras ocasiones toma más de 10 minutos el pensar y programar una prueba unitaria, aunque al principio cuando se está aprendiendo puede que tome más.
Conclusión
Dada la importancia que conlleva realizar pruebas unitarias en el proceso de desarrollo de software, como desarrolladores debemos entender que es un trabajo propio del desarrollador y que ello no conlleva una dificultad sino más bien agiliza la corrección de errores.
En Rootnite entendemos la importancia de las pruebas unitarias y como expertos en desarrollo con Java en unos próximos artículos realizaremos entradas relacionadas con pruebas unitarias.
