Elegiendo un Isolation Framework.

Hay dos cosas que debes tener en cuenta al elegir tu framework de aislamiento.

  • ¿ Tu framework es estricto o no estricto?.
  • ¿Tu framework es restringido o no restringido?.

¿Que es un framework estricto/no estricto (strict/ non strict)?.

Un framework estricto es aquel que exige que inicialices o prepares todo elemento que harás Mock o Stub, esto se nota en las propiedades y atributos de una clase, por ejemplo: creas tu objeto falso haces Assert de una propiedad de la clase, y oh sorpresa tienes una bonita NullPointerException en el caso de Java, o NullReferenceException en el caso de .Net . Si quieres trabajar con un objeto falso TODA la inicialización corre a tu cargo si estas ocupando un framework estricto. Incluso es posible que usar un elemento no inicializado arroje un Fail.

En un framework no estricto la inicialización de todos los elementos de un objeto se hace por defecto y el declarar un Fail corre a tu cargo.

¿Que es un framework restringido/no restringido (constraited/non-constraited)?.

La mayoría de los frameworks de aislamiento (los restringidos) crean objetos falsos a partir de la herencia y creación dinámica de tipos(en el caso de Java y .Net), esto tiene varias implicaciones, las menciono:

  1. Debes poder tener clases , superclases, clases abstractas o interfaces que puedan heredarse para poder crear objetos falsos, esto es particular molesto desde el punto de vista de la arquitectura del sistema. Tienes un elemento externo, las pruebas, que fuerzan las reglas de negocio de un modo poco natural.
  2. No puedes hacer objetos falsos de todo, esto quiere decir que hay cosas que no podrás probar directamente como métodos estáticos, funciones del sistema, etc.

En este punto, los frameworks no restringidos suenan mejor, y los son. La principal contra de los frameworks no restringidos es: todos los non-constraited isolation frameworks son de pago (al menos en el ecosistema .Net).

Ya que tienes claro las opciones de Framework de aislamiento disponibles y elegiste tu caballo de batalla debes de tener en cuenta lo siguiente:

El framework de aislamiento es el ultimo recurso, no el primero.

Cuando conoces las delicias de la creación de objetos falsos en las pruebas, quieres usarlos para todo, con el problema de hacer innecesariamente mas complejas tus pruebas. Antes de crear un Mock o un Stub asegúrate que has reducido las dependencias al mínimo a través de buenas practicas.

Primero va SOLID, luego el framework de aislamiento.

Si diseñas componentes con una única responsabilidad, desacoplados, genéricos y de baja complejidad las pruebas unitarias son la consecuencia natural, no la causa. Probar componentes altamente acoplados puede ser muy improductivo, las pruebas sobre ese tipo de componente tienden a ser frágiles.

Las Unit Tests son un modulo mas del sistema, tratalas como tal.

Cuando te comprometes a tener pruebas unitarias en tu código base, debes tratarlas con el mismo respeto que tu código productivo, no es algo que puedas usar de vez en cuando o dejar para cuando tengas un tiempo libre.

 

Autor imagen: Thomas Quine

Gustavo Sánchez