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

Question

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

Answer 1

Respondió a una pregunta similar hace unos días aquí, burlándose un Singleton . La publicación original es para C # .Net en lo que respecta a burlarse del comportamiento de un singleton, pero aún debe aplicarse.

Con respecto al patrón singleton, no hay nada malo en sí mismo; en muchos casos, queremos centralizar la lógica y los datos. Sin embargo, hay una gran diferencia entre un singleton y una clase estática. Construir su singleton como códigos duros de clase estática que implementan para cada consumidor en su aplicación, ¡lo que hace que las pruebas unitarias sean muy difíciles!

Lo que desea hacer es definir una interfaz para su singleton, exponiendo los métodos para que los utilicen sus consumidores. A su vez, a sus consumidores se les pasa una referencia a una clase de implementación por quien sea que los instaure [normalmente esta es su aplicación o un contenedor si está familiarizado con la Inyección de dependencia \ Inversión de control].

Es este marco, cualquiera que esté creando instancias de los consumidores, 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 pierdes la comodidad de una instancia accesible a nivel mundial: lo sé, las referencias globales son terriblemente seductoras, pero Luke le dio la espalda a la Lado oscuro, ¡tú también puedes!

En términos generales, las mejores prácticas sugieren evitar referencias estáticas y alienta la programación contra interfaces. Recuerde, todavía es posible aplicar el patrón singleton con estas restricciones. Siga estas pautas y no debería tener problemas para que la unidad pruebe su trabajo :)

¡Espero que esto ayude!

---

singleton! = clase estática pública , en lugar de singleton == instancia única

Answer 2

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

Si realmente necesita tener una instancia singular, entonces la inyección de dependencia y la escritura en una interfaz, como sugiere johnny g, es definitivamente el camino a seguir.

Answer 3

Estoy usando el siguiente patrón cuando escribo un singleton basado en estática que puedo burlarme. El código es Java, pero creo que tendrás una idea. El principal problema con este enfoque es que tienes que relajar el constructor a un paquete protegido (lo que derrota un verdadero singleton). Como nota al margen: el código se aplica a la capacidad de burlarse de su " estática " código no necesariamente simplemente llamándolo

Answer 4

Generalmente solo uso Singletons para objetos Flyweight u objetos de valor similar. Examinar un contenedor de IoC (como se discutió anteriormente) es probablemente una mejor manera de manejar un objeto compartido que un singleton.

Considere que en Smalltalk (donde se originaron muchos de estos patrones), verdadero y falso eran ambos, en realidad, singletons :)

Answer 5

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

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