Prepara tus clases para uso en modo simulado o real

En muchos desarrollos se da el caso de que uno o varios de los componentes del proyecto deben de probarse previamente (o debería de ser así) antes de entrar en producción. Por ejemplo, no sería deseable que se hiciese efectivo el envío de cientos de email a los destinatarios de una base de datos simplemente porque tengas que probar uno de los pasos en el flujo de la solución, ¿verdad?

De igual modo, tampoco es necesario enviar repetidamente mensajes de correo a varios destinatarios reales de la base de datos si lo que deseas es comprobar es que estos llegan correctamente; hacerlo sobre unas pocas direcciones de correo que estén bajo tu control es una mejor opción. La idea está clara: conviene establecer algún mecanismo que permita indicar a la solución cuando ha de comportarse en modo real o en modo simulado para todos o algunos de los componentes que debas de probar en cada ocasión. A continuación te explico una de las vías, que igual puedes encontrar interesante para aplicarlo en tus propios proyectos.

En realidad el modo de afrontarlo es bastante simple, y se basa en la definición de una propiedad booleana para cada una de las clases (por ejemplo, con el modo simulacion) para ajustarla bien desde código o bien desde el Panel Inspector a través de la característica Inspector Behavior.

Luego en la clase implementarás los métodos públicos que serán los utilizados (invocados) por el resto de la aplicación, salvo que aquí la única diferencia que deberás de tener en cuenta es que crearás otros dos métodos privados por cada uno de los métodos públicos en los que sea necesaria su ejecución en modo real y en modo simulado.

Por ejemplo, pongamos por caso que uno de los métodos de nuestra clase, denominado GetData es el responsable de obtener los datos a emplear en un paso posterior como resultado de una consula a una base de datos, y que devolverá como resultado un Array de Diccionarios. Sin embargo, cuando deseamos comprobar otro paso de la solución es suficiente con que pasemos unos cuantos registros con los cuales trabajar, evitando así la necesidad de establecer y realizar la consulta sobre la base de datos remota y tener que procesar cientos o miles de registros. En este caso, podríamos definir los siguientes métodos en la clase:

• GetData() As Xojo.Core.Dictionary(). Método público de la clase que será el invocado por los consumidores de la misma.
• GetRealData As Xojo.Core.Dictionary(). Método privado de la clase que será el invocado si la propiedad simulacion está ajustada con el valor False.
• GetSimulationData As Xojo.Core.Dictionary(). Método privado de la clase que será el invocado si la propiedad simulacion está ajustado con el valor True.

Luego, el código real del método público será simplemente este:

return if(simulacion = true, GetSimulationData, GetRealData)

Sencillo, ¿verdad? Con este sistema tendrás la máxima flexibilidad a la hora de decidir qué partes de la solución quieres probar simplemente: todas, ninguna, sólo parte de ellas… El único “inconveniente” es que una vez que quieras compilar la aplicación para su distribución, o para que entre en producción, tendrás que acordarte de poner todas las propiedades simulacion de las clases a False; aunque seguro que se te ocurre como puedes hacelo con una ligera modificación del código! (pista: recuerda que tienes los condicionales de compilación a tu disposición, como por ejemplo la constante DebugBuild.)