Mis mocks me hacen pensar

En la última entrada del blog comentaba el significado de la ilusión de competencia. Solventar el mismo problema una y otra vez es buena idea hasta conseguir automatizar la solución; una vez sobrepasado este umbral aparece el riesgo de creer que nos estamos acercando a la maestría, pero no es la realidad, es una ilusión. O resumido en una frase, diez años de experiencia no es lo mismo que un año repetido diez veces.

En este post escribo un ejemplo de como la ilusión de competencia montada en un monster truck me ha atropellado y no la he visto venir. Esta vez incluyo un poco de código. Resulta que yo de siempre he sido de rspec, una gema en Ruby que sirve para hacer tests de código. He usado rspec durante años a diario hasta que me pasé a minitest (otra gema de testing) para los coding dojos. minitest es poco más rudimentaria, más simple en la cantidad de herramientas que ofrece, con menos addons.

Por ejemplo, una feature de rspec muy útil son sus mocks. En el siguiente ejemplo se testea la colaboración de RemoteServices con VoiceService, el SUT.

Sin entrar a discutir la inyección de dependencias en Ruby, lo considero un test válido para un servicio con poca complejidad.

Por su parte, los mocks de minitest (sin requerir plugins) siguen otra filosofía. En contraposición a la feature de rspec que intercepta el objeto, minitest solamente permite utilizar dobles para los mocks. El test quedaría tal que así.

Como se puede apreciar, minitest fuerza a introducir una inyección de dependencias clásica cuando se utilizan los mocks. A decir verdad, con rspec también es posible hacer este tipo de tests, aunque es mucho más cómodo interceptar el objeto que implementar la inyección de dependencias. Es debatible que una sea mejor que otra, lo importante es elegir conscientemente.

Este sutil cambio de perspectiva, simplemente sustituyendo el framework de test, me ha llevado a dos reflexiones. La primera, como he comentado al principio, es que por usar una herramienta (gema) todos los días, no quiere decir que sea maestro ni en la herramienta ni en el problema. En este caso la herramienta es muy versátil, pero he fallado en preguntarme por qué la uso de una determinada manera para un tipo específico de problema. Podría ser por tradición, o por comodidad, o porque en realidad es la mejor forma. Lo importante es preguntarse las razones, incluso introducir cambios de vez en cuando y volver a medir la mejor opción.

Por otra parte, la elección de las herramientas guía en exceso decisiones de implementación. La capacidad de resolver problemas es moldeada por las herramientas disponibles, en ocasiones adoptando soluciones subóptimas en aras de la comodidad o de adaptarnos a las convenciones de la comunidad (seguir la corriente).

¡Espero que sea una lección aprendida y la próxima vez verlo venir antes de que me pase por encima!

https://flic.kr/p/ogwYm