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?.

¿Qué 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 estás 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.

¿Qué 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 generar 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 último 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 más 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 prácticas.

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 módulo más del sistema, trátalas 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 utilizar de vez en cuando o dejar para cuando tengas un tiempo libre.

Referencias:

• The Art of Unit Testing.

Autor imagen: Thomas Quine

• Acerca de
• Últimas entradas

Gustavo Sánchez

Especialista en escribir software de calidad. en Happy Devops

Soy especialista en escribir software de calidad. Mediante el uso de marcos de trabajo, técnicas y automatización de procesos he podido reducir los costes operativos de los sistemas de la empresa. Sistemas confiables y adaptables producen clientes felices.

Últimas entradas de Gustavo Sánchez (ver todo)

• NVL in SQL Server - 2023-11-01
• ¿Que es Cake Build? - 2023-02-22
• #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20