Pruebas unitarias: MythBusters

Aunque los beneficios de las pruebas unitarias puedan parecer claros, no es más cierto que a día de hoy se usan en muy pocos proyectos. Pero sin son tan buenas,¿por qué no se usan?

Pues la razón principal es que existen bastante desconocimiento en esta materia, poca tradición y algunos falsos mitos.

Uno de los mitos es creer que escribir pruebas unitarias es escribir el doble de código; escribir el código de la aplicación y escribir el código de pruebas. Escribir una prueba nunca es escribir el doble de código, aunque lógicamente sí es escribir más código. El mito es totalmente falso.

Las pruebas siempre se deben ir escribiendo a medida que se desarrolla el software. A medida de desarrollamos vamos probando nuestro código lo que nos permite asegurar que el módulo queda terminado correctamente, libre de incidencias.

La realización de pruebas unitarias debe ser un proceso obligatorio en nuestros desarrollos y que no queden a la voluntad del desarrollador. Si el desarrollador no está habituado a su uso diario es muy fácil que tienda a evitar realizar este tipo de pruebas.

Si no estás familiarizado con el uso de pruebas unitarias la perseverancia debe ser tu gran aliado. Debes estar convencido de que el uso de pruebas unitarias es el enfoque correcto y no ser flexible; las pruebas unitarias no son opcionales y deben realizarse a medida que se desarrolla.

Dejar la implementación de pruebas para el final no es realista, ya que las pruebas nunca se llegarán a implementar y si lo hacen, serán de una baja calidad, ya que la persona que las realiza considerará que es una pérdida de tiempo, considerando que su tarea ya estaba terminada sin realizar estas pruebas.

¿Y si no escribiéramos este código cómo probamos? Pues la experiencia me dice que hay diferentes situaciones.

La primera situación es que no se prueba. Se implementa el módulo pero no se prueba, dando por hecho que nuestra experiencia como desarrolladores hará que las incidencias sean mínimas. Cuando tenemos todos los módulos lo probamos de forma integrada a través de pruebas funcionales.

Esta situación es la situación peor con la que podemos encontrarnos, pero desgraciadamente es la más habitual. Los tiempos de integración, depuración y corrección de incidencias se multiplican. El tiempo que va desde que consideramos que el producto está terminado hasta que realmente está terminado puede llegar a ser superior al tiempo invertido en el desarrollo, y lo digo por experiencia, por mala experiencia.

Otra situación algo mejor, es el uso de aplicaciones de pruebas de usar y tirar. Todos hemos implementado aplicaciones tontas, generalmente de consola, para probar el módulo que estamos desarrollando y que posteriormente integraremos en un sistema mayor.

La situación no es la ideal pero realmente el desarrollo de pruebas unitarias puede tener una semejanza con este tipo de aplicaciones, siendo éste último concepto más avanzado y mejorado para que pueda ser reutilizable, independientes y completas.

Estas aplicaciones de usar y tirar nos valen para la primera vez y si somos exhaustivos nos permitirá probar bien nuestro módulo. La realidad nos dice que esta aplicación se tira y que ante cualquier modificación en el módulo nos comportamos como en la situación primera, en las pruebas con sistema completa y pruebas funcionales.

Otro mito, unido al anterior, es que desarrollar pruebas unitarias hace que los tiempos de desarrollo se incrementen, incrementando los costes del proyecto.

Entre desarrollar y no probar y desarrollar haciendo pruebas unitarias, reconoceré que es más rápido desarrollar sin probar…..pero creo que esto no nos vale….así que entre desarrollar con pruebas unitarias y desarrollar probando con métodos más rústicos, ésta segunda es más lenta y por tanto, más cara.

La manera más rápida de desarrollar software es desarrollarlo bien. Como hemos comentado en el punto anterior, si no desarrollamos código de calidad y no realizamos pruebas, los tiempos de desarrollo se podrán disparar enormemente; tiempo de integración, tiempo de depuración, tiempo de incidencias etc…

Pero hay un problema mayor; la pérdida de confianza del cliente. Un producto de baja calidad, lleno de incidencias es la peor tarjeta de presentación.

Por otro lado, hay que tener en cuenta que cuando más larga sea la vida de la aplicación más beneficios se obtendrán del sistema de pruebas unitarias.

Muchos productos tienen un mantenimiento evolutivo que implica el desarrollo de nuevas funcionalidad y la corrección de incidencias. Sin un proceso adecuado de pruebas unitarias, los tiempos de pruebas se dispararán en fases posteriores, ya que será necesario probar y corregir tanto las nuevas funcionalidades como las funcionalidades ya existentes.

Cierto es también que la adopción de pruebas unitarias dentro del equipo de desarrollo implica una inversión en formación. La primera vez que las empleemos llevará algo más de tiempo ya que tenemos que familiarizarnos con las herramientas y con el framework de pruebas unitarias. Este tiempo es algo habitual asociado a cualquier proceso de aprendizaje que sólo sería imputable al primer proyecto que se desarrolle.

Ibon Landa

bon Landa lleva más de 15 años dedicado al desarrollo de software. Durante este tiempo ha trabajado en diferentes empresas en las cuáles ha podido trabajar en diferentes entornos y tecnologías. Actualmente está focalizado principalmente en tareas de desarrollo, arquitectura, en las herramientas del ciclo de vida y en todo lo relacionado con la plataforma de Cloud Computing Microsoft Azure, área en el que ha sido reconocido como MVP. Participa de forma activa en la comunidad, escribiendo su blog, manteniendo un portal sobre Microsoft Azure y colaborando con Microsoft y grupos de usuarios en eventos de formación, talleres y giras de producto.

7 comentarios en “Pruebas unitarias: MythBusters”

  1. ¡Aúpa titán!

    Comparto todo lo que comentas. Yo creo que se resume en ver las pruebas unitarias como una inversión, no como un coste. Las pruebas unitarias acaban dando unos rendimiento espectaculares a lo largo del tiempo de vida del proyecto, pero claro, en sus inicios exijen realizar una pequeñas inversión.

    Un saludo.

  2. Ibon, excelente !!!

    y como bien dices, el problema está dado mayormente por la creencia popular del «trabajo extra» que requiere desarrollar con pruebas unitarias.

    Aunque también existe un punto a nombrar: la arquitectura de desarrollo. Quieras o no, cuando creas pruebas unitarias y te acostumbras a trabajar con las mismas, este modo de trabajo afecta al diseño que hacemos de clases, componentes, servicios, etc.

    Y en algunas oportunidades me he visto en una situación donde debía «justificar» (no se si es la mejor palabra) algunos ajustes de diseño para ser más ágiles con las pruebas … vamos que como dice Rodrigo, justificar una serie de inversiones iniciales que después se ven mucho más adelante 😀

    Saludos

  3. Totalmente de acuerdo.

    Una pregunta al Bruno y un comentario.

    La pregunta:

    ¿Puedes poner algún ejemplo de esos «Ajustes de diseño» para ser más ágiles con las pruebas?

    El comentario:

    El problema es que muchas veces el cliente quiere algo «para ya»….y te fuerza a recortar tiempo….y lo primero que recortas es la creación de esas pruebas unitarias.

    El cliente se queda contento….porque el proyecto se cerró en el tiempo requerido…..pero todos sabemos que luego hacer el mantenimiento es mucho más costoso, y que resolver cualquier incidencia, por tonta que sea, puede convertirse en un desafío.

  4. Hola GusiLuz,

    El «para ya» es el típico error que se comete. ¿»Para ya» significa que hay que entregarlo sin probarlo?

    Si significa que tenemos que entregar algo aunque esté sin probar sí que se entrega más rápido pero si hay que entregar algo probado y correcto, con pruebas unitarias se entrega más rápido.

    Si recortas en las creación de pruebas unitarias, estas recortando en las pruebas. Si tu jefe no lo entiende, evita la palabra unitarias….porque lo típico suele ser recortar en aquello que no se entiende.

    Por otro lado, como bien comenta Bruno, hacer pruebas unitarias te puede ayudar a generar mejores arquitecturas. Sobre una buena arquitectura es «fácil» meter pruebas unitarias, sobre una mala complicado o imposible.

  5. Hola Ibon.

    Pues habitualmente «para ya», suele significar que algo que tienes planificado para cinco días, con sus buenas pruebas unitarias y demás, tienes que tenerlo en dos días…..

    ¿Entregarlo sin probar? Bueno, entregarlo como dices tú en tu primera opción…. Unas pruebas de funcionalidad, que pasa, y a correr.

    Evidentemente, y tienes más razón que un santo….cuando llegan las incidencias hay veces que pierdes media hora en localizar la incidencia….con unas buenas pruebas rápidamente sabes dónde falla y en dos minutos la puedes tener arreglada.

    Y eso por no comentar el hecho de la tranquilidad que te da modificar algo de código contando con una buena batería de pruebas que validen posibles efectos secundarios, que cuando no tienes esas pruebas te da miedo hasta tocar….

    Un saludo!

  6. Hola!

    Lo más importante no es que cuando vengan las
    incidencias encontrarás más fácil la solución, sino que la incidencia no llegue al cliente.

    Hay veces que parece que lo más importante es entregar algo, sin importar cómo esté lo que se le entregue.

    Ya me contarás cómo pasas de 5 días a 2 días y no morir en el intento 🙂

  7. cazadores son los mejores cadamañana me encanta todo lo que hasen soy su fan. Es posivle esconderse en un lado de un arbol de 20 c.m de ancho

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *