Como fracasar con las pruebas unitarias

Hace poco gravé un pequeños video en el que explicaba una realidad que he visto en muchos proyectos respecto de las pruebas unitarias. En síntesis lo que comentaba era que en esos proyectos, los beneficios de las pruebas unitarias no eran visibles mientras que los costos sí lo eran.

En problema aparente era la calidad de las pruebas, pero en realidad, el problema de fondo es la estrategia de hacer las pruebas luego de terminado el código. Por lo general, los programadores escriben piezas de código las cuales, para probarlas, son ejecutadas manualmente varias veces mientras que con el depurador se recorren línea por línea los algoritmos. Una vez que la feature está lista, quieren escribir algunas pruebas pero apenas de empezar se dan cuenta que el código que han escrito no es fácilmente testeable, no contempla la posibilidad de inyectarle las dependencias y probablemente han utilizado muchos de lo “enemigos de las pruebas unitarias”.

Aquí el programador puede tomar un de los siguientes caminos:

  1. Refactorizar el código para volverlo testeable.
  2. Probarlo como está, es decir, si el código toma valores de una tabla de la base de datos, pueden ponerle esos valores en la tabla al iniciar la prueba.
  3. No probarlo en absoluto. Esta es (Test-Never)

Estas decisiones no son libres ya que hay ciertos condicionamientos:

  1. Queda poco tiempo. Todo lo que se pudo ahorrar en depuración ya se perdió y ahora no solo se trata de escribir las pruebas sino que hay que refactorizar algo que “ya está andando” para recién luego escribir las pruebas.
  2. Probablemente esa refactorización no sea algo tan sencillo. Es probable que haya que modificar algo más de código que solo el propio. Esto ocurre cuando hay que lidiar con los métodos estáticos y otras malas yerbas ya presentes en el proyecto.
  3. El resto del equipo ya se ha encontrado en este dilema y la decisión que han toma es un antecedente de peso en la cultura del equipo.

Cual de los caminos toma el programador depende de muchos factores pero lo malo del caso es que ninguna de las tres alternativas conduce a algo bueno. Veamos por qué:

En el primer caso, se consume mas tiempo que el que se hubiese requerido si el código se hubiese hecho testeable desde el principio mediante TDD. Es probable que el programador vea esto como una pérdida de tiempo ya que su código “funciona” pero él tiene que modificarlo para “cumplir” con algo, llámese cobertura de código, número de pruebas, etc.

En cuanto a la segunda alternativa, la de probar sin modificar el código, es sin dudas un camino para realizar pobres pruebas de integración. Solo hay que hacerlas y esperar algo más de un año para ver el daño que que hacen al proyecto, cuanto cuestan y cuán poco sirven.

La tercera opción es la más coherente con el modo de desarrollo que se ha tomado pero es sin dudas una estafa. Si se ha estimado el tiempo necesario para codificar las pruebas y si ha comprometido con el equipo ha escribir pruebas para el código propio y pero no se lo lleva a cabo, entonces hay que sincerar la situación.

No interesa que tan buen programador sea, si no se escriben la pruebas interactivamente con el código se llegará tarde o temprano a esta situación.

Sin categoría

One thought on “Como fracasar con las pruebas unitarias

Responder a anonymous Cancelar respuesta

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