Resulta obvio decir que una prueba unitaria que involucre una API de terceros será, cuando menos, disfuncional, y hablando con honestidad, una pieza de código que jamás debería integrarse al proyecto. Sin embargo, con las bases de datos, parecería que suele hacerse una excepción. Antes de continuar, plantaré una premisa simple: en una prueba unitaria sólo debe probase aquello que, tras ser ejecutado en diferentes entornos, tendrá el mismo comportamiento esperado.

Intro ¿Cómo podemos probar esto localmente? - preguntó el desarrollador. No podemos - respondió el arquitecto. Esa fue la frase que inició mi viaje hacia el mundo de las pruebas unitarias. ¿Cómo puedo garantizar un minimo nivel de calidad sobre algo que deifnitivamente no puedo probar, debido a dependencias externas y limitaciones de infraestructura? Y no siempre es cuestión de “arrojarlo a producción y ver que pasa”, ya que en muchos casos, el costo de un error puede ser muy alto; ciertos procesos involucran transacciones monetarias, o datos sensibles de y para los usuarios, y un error puede significar una pérdida de dinero, o una violación de una norma o una ley.

TDD es un gran avance en la ingeniería de software. Es una técnica que nos proporciona un feedback claro sobre si nuestro código hace lo que esperamos y, aún más importante, si nuestro diseño es suficientemente bueno. Aunque no es fácil y puede parecer antinatural para los que son nuevos, la clave es la práctica. No se trata de ser bueno en testing sino en volverse bueno en el diseño.