Xuaps

Matraces

Test más allá de la calidad

El otro día impartí una formación interna en mi empresa sobre testing, y voy a intentar hacer una transcripción lo más fiel posible. Por cierto en Quobis estamos buscando gente.

¿Por qué hacer tests?

Los testers hacen tests. Los programadores hacen tests. ¿Cuál es la diferencia? El propósito de dichos tests. Los testers hacen tests para encontrar bugs y esta es sólo una de las muchas herramientas que pueden usar.
Por el contrario, los desarrolladores no hacemos tests para encontrar bugs, los motivos para hacer test pueden ser muchos y variados, para mi los principales son los siguientes:

  • Tener especificaciones ejecutables. Ya sabéis, documentación viva de esa que se actualiza.
  • Detectar efectos laterales. No hay nada que te infunda de más valor que una buena batería de tests. Que hay que meter nueva funcionalidad y cambiar una parte del código, no hay problema, sé que todo seguirá funcionando.
  • Con la proliferación de los lenguajes dinámicos, débilmente tipados, etc… hay un buen puñado de problemas que ya no podemos detectar en tiempo de compilación, una buena batería de tests no ahorrará muchos quebraderos de cabeza.
  • Nos ayudan a diseñar. Con esto no digo que hacer tests te provea de algún tipo de superpoder para diseñar tu software, no, no es eso. Los tests son sólo otra herramienta más, pero una herramienta que bien usada y siguiendo el ciclo TDD te sitúa en una perspectiva totalmente distinta a la hora de tomar decisiones de diseño.
  • (Añadir aquí vuestras razones)

¿Qué testear?

Lo fácil sería decir: “todo”. Pero es absurdo, no todo vale la pena desarrollarlo con tests, ni tampoco es necesario. Cosas que yo suelo testear:

  • Lógica
  • Bugs
  • Fronteras con el mundo exterior
  • Integración de distintas piezas
  • The User Journey
  • Piezas de código que requieren exploración o darle una pensada.
  • … cualquier cosa que te aporte valor

Una pregunta más dificil es qué no probar. Yo nunca pruebo:

  • Código que no es mio
  • Código boilerplate

¿Cuánto?

Todo lo que puedas.

¿Qué tiene todo esto que ver con la calidad?

¿Con qué calidad? Si hablamos de la calidad interna de nuestro código, ¿es un código con test de mayor calidad? Bueno no creo que los tests por si solos te conduzcan a un código de mayor calidad. Necesitas aplicar más superpoderes, patrones, principios, buenas prácticas etc… Y si hablamos de la calidad externa, la que percibe el usuario, tampoco creo que la puedas asegurar por el echo de tener tests, recuerda que tu y yo no hacemos tests para buscar bugs. Sin embargo, bien usados, son una buena herramienta para asegurar que lo programado funciona y además es lo que el usuario espera.

¿Son valiosos?

Tendrás que fiarte de mi palabra pero lo son. Incluso en aquellos proyectos en los que los tests se nos fueron totalmente de las manos y eran complejos, lentos, no unitarios… los programadores, entre los que me encontraba, encontrábamos valor en mantenerlos y seguir haciéndolos.

¿Lo estoy haciendo bien?

Puedes complicarte la vida todo lo que quieras con métricas, pero para mi la única métrica que vale es el “dolor”. Ya sabes si estás escribiendo un buen código, ya sabes si está acoplado o sino tiene suficientes test. Ya sabes todo eso, porque sabes que si “duele demasiado” es que algo no va bien.

Para concluir te diré que para asegurar la calidad de tu producto los tests automáticos que hacemos los desarrolladores no son ni de lejos suficientes pero no por ello son opcionales. Hacer tests forma parte del proceso normal de desarrollo, igual que hacer un código limpio o un buen diseño. No hay excusa para no hacerlos, así que no las busques.