Como pensar el testing

Existen 2 visiones sobre el testing (que yo conozca). La primera y me parece que es la más difundida es la de hacer test de unidad para cada clase. Se aísla la clase y se hacen mocks de todas las clases con la que se comunica la clase que queremos probar. Se hacen test por cada método en la clase, lo cual representa dificultad extra cuando los métodos son privados. También se hacen test para verificar que las clases se instancian de manera correcta y luego se hacen test con las clases reales en vez con los mocks.

Voy a pensar en las cosas positivas de hacer los test de esa forma. Bueno si alguien modifica algo en las clases o no se hace de forma correcta, siempre y cuando los test estén bien hechos podemos encontrar rápidamente dónde está la porcion de codigo que esta fallando. No se me ocurren otras ventajas. Si tu sabes de otras ventajas por favor déjalas en los comentarios, realmente me gustaría conocerlas.

Pensemos en las desventajas. Lo primero que se me viene a la mente es que por cada clase que existe hay que hacer muchísimo trabajo de testing. Solo pensar que hay que testear cada método, y que hay que programar cada mock, stub y spy.... es desmotivador.

Segundo. Si ya terminamos de hacer el arduo trabajo de hacer todos los test. Y más adelante hacemos un refactor en los métodos de alguna clase, tendremos que modificar todos los test donde usemos esos métodos modificados. Y si en vez de refactorizar métodos en una clase, extraemos comportamiento en una clase nueva, debemos modificar cada test del cual modificamos la clase \ las clases que refactorizamos y encima hacer nuevos test para la nueva clase. La mayoría del tiempo estaríamos modificando mocks, código falso. De alguna forma pareciera que estuviéramos haciendo testing a los mocks más que a nuestro código productivo.

Sobre los spy. Estos están destinados a corroborar el comportamiento o el estado privado de nuestros objetos. Pensemos en la siguiente analogía. Quiero instalar la televisión por cable en mi casa. Entonces llamó al señor instalador. ¿Qué cosa me importa del señor instalador? ¿Me importan todos sus pensamientos privados? Como podría ser que le tiene que comprar un regalo a su mujer porque se acerca su aniversario o que cuando termine tiene que pasar por el almacén porque se le acabaron los víveres o cualquier otra cosa. O mejor aun ¿me tiene que importar si para instalar va pelear los cables con una pinza, o usar algun cortaplumas o si tiene alguna herramienta especializada? No, no me importa sus pensamientos privados, ni tampoco que tecnicas va a usar. Solo me importa que me instale bien el cable. Instalar el cable es su comportamiento público, él es el señor instalador del cable, a eso se dedica y es lo único que me debería importar, que haga bien su trabajo. Como lo haga es una cuestión de él. ¿Ves la relación entre lo que digo y los spy?¿Y con los demás test?

Otros inconvenientes que conozco de hacer este tipo de test, es que cuando el sistema a testear es muy grande. Los test son muchísimos y pueden tardar muchas horas en correr. Muchas horas. Bueno... ni quiero pensar en todos los problemas que derivan de esta situación pero el peor de todos seguramente sea que a la larga se deje testear.

Otra forma de testear es, simplemente testeando el comportamiento que espera el usuario del programa. Después de todo es lo que importa. En esta forma de pensar los test, ya no es necesario los test unitarios por cada clase. No me importa demasiado lo que hace cada método, solo me importa que el comportamiento sea el esperado. Si el señor del cable fuera una clase e "instalarCable" un método público y por lo tanto es el comportamiento que espero de esa clase. No me importa como lo hace, no importa cuantos procesos internos use, cuántos métodos privados utilice. Solo importa que instale el cable y listo. Si hago refactors el test no se entera (siempre y cuando no cambie los nombres del protocolo público) y si no se entera no tengo que modificar los test. Ahora mi vida se hizo mucho más fácil.

Se debe testear comportamiento, no se debe testear métodos.

Bueno ¿y los mocks entonces?¿Sirven para algo?

La idea de los test es que sean rápidos. No deberían tardar más de 10 min aprox. Así que si hay algun test que haga uso de una clase cuyo comportamiento tarde mucho. En esos casos podría utilizarse un mock para disminuir el tiempo de testing. Una vez que estos test pasen, podría haber otros tests que hagan comprobaciones más exhaustivas.

Bueno eso es lo que pienso sobre testing, Me gustaria saber que piensas tu, tal vez haya situaciones en las que no haya pensado.

Dejo el video que me inspiró a escribir sobre esto: