¿Cómo puedo probar una clase de Singleton con DUnit?

Question

¿O es mejor usar otro patrón de diseño?

Answer 1

Respondido a una pregunta similar hace unos días here, mocking a Singleton. La publicación original es para C# .Net en lo que respecta a la burla del comportamiento de un singleton, pero aún debe aplicarse.

En cuanto al patrón singleton, no tiene nada de malo, en muchos casos queremos centralizar la lógica y los datos. Sin embargo, hay una gran diferencia entre una clase única y una estática. Al crear su singleton como una clase estática, los códigos duros se implementan para cada consumidor en su aplicación, lo que hace que las pruebas unitarias sean muy difíciles.

Lo que quiere hacer es definir una interfaz para su singleton, exponiendo los métodos para que los consumidores utilicen. Sus consumidores a su vez son pasaron una referencia a una clase implementadora por quien los crea [normalmente esta es su aplicación, o un contenedor si está familiarizado con Dependency Injection \ Inversion of Control].

Es este marco, el que está creando instancias de los consumidores, el responsable de garantizar que una sola instancia esté flotando. Realmente no es un gran salto de la clase estática a la referencia de interfaz [como se demostró en el enlace anterior], simplemente se pierde la conveniencia de una instancia accesible a nivel mundial - sé que sé, las referencias globales son terriblemente seductoras, pero Luke le dio la espalda al Lado oscuro, ¡tú también puedes!

En términos generales, las mejores prácticas sugieren evitar referencias estáticas y fomentan los programas contra las interfaces. Recuerde, todavía es posible aplicar el patrón Singleton con estas restricciones. Siga estas pautas, y no debería tener ningún problema para probar la unidad de su trabajo :)

Espero que esto ayude!

---

Singleton! = Pública clase estática, en lugar Singleton == única instancia

Answer 2

I'm using the following pattern cuando escribo unos únicos basados ​​en estáticas que puedo simulado. El código es Java, pero creo que tendrás una idea. El problema principal con este enfoque es que tiene que relajar el constructor con el paquete protegido (que sorta derrota a un singleton verdadero). Como nota al margen: el código se aplica a la capacidad de burlarse de su código "estático" no necesariamente simplemente llamándolo

Answer 3

La falta de capacidad de prueba es una de las mayores caídas del modelo Singleton clásico (método de clase estática que devuelve una instancia). En lo que a mí respecta, eso es justificación suficiente para rediseñar cualquier código que use Singletons para usar algún otro diseño.

Si necesita absolutamente tener una instancia singular, la Inyección de Dependencia y la escritura en una interfaz, como lo sugiere johnny g, es definitivamente el camino a seguir.

Answer 4

Si debe usar un singleton (y hay razones para hacerlo ... pero siempre trataré de evitarlo si es posible). Yo recomendaría usar un contenedor IOC para administrarlo. No estoy seguro si hay uno para Delphi o no. Pero en Java puedes usar Spring, en .NET puedes usar Windsor/Castle. Un contenedor de IOC puede contener Singleton y puede registrar diferentes implementaciones para probar.

Es probable que sea un tema demasiado grande para entrar aquí más allá de este fragmento.

Answer 5

Por lo general, solo uso Singletons para objetos Flyweight u objetos de valor similar. Ver en un contenedor IoC (como se discutió anteriormente) es probablemente una mejor manera de manejar un objeto compartido que un singleton.

considerar que en Smalltalk (donde muchos de estos patrones se originó), verdadero y falso eran los dos únicos efectivamente :)