Singleton y testing

[AlejandroDeheza]

Hola, buenas noches!

Consulta, si a un Singleton le pongo el constructor en publico (al menos en java) ¿No permitiría hacer test unitarios mas fácilmente? Supongo que ya no seria un Singleton pero, se podria acordar usar el "getInstance()" para que entregue siempre la misma instancia (para usar en el código), y usar el "new PseudoSingleton()" para generar nuevas instancias para los tests

¿Esto podria ser útil para aprovechar lo bueno de un Singleton y tener test unitarios independientes? o presenta mas problemas que soluciones?

Saludos!

public class PseudoSingleton{

  private static PseudoSingleton INSTANCE;

  //usariamos el constructor solo para tests
  public PseudoSingleton() { }

  //usariamos el getInstance en el codigo
  public static PseudoSingleton getInstance() {
    if (INSTANCE == null) {
      INSTANCE = new PseudoSingleton();
    }
    return INSTANCE;
  }

  ...
  //atributos y comportamiento que le den utilidad a esta clase
  ...

}

[gastonprieto]

Buenas @AlejandroDeheza

Si podrías hacerlo público, pero eso solo serviria cuando vos sos el que hace el new, por ejemplo para probar el PseudoSingleton.

El problema con el singleton es que normalmente se usa con el getInstance() desde adentro de otros objetos, entonces en principio no tenes forma de parametrizarlo porque esta fijo en el código esa llamada.

Para resolver estos problemas entra en juego la inyección de dependencias así logramos la parametrización.

[flbulgarelli]

Una detalle más sobre esta parte del código:

  //usariamos el getInstance en el codigo
  public static PseudoSingleton getInstance() {
    if (INSTANCE == null) {
      INSTANCE = new PseudoSingleton();
    }
    return INSTANCE;
  }

Contra la creencia generalizada a través de muchos libros y blogs, el if no es parte esencial del singleton sino de la inicialización diferida, y en la mayoría de los casos no sólo hace al código más complejo sin un verdadero beneficio (el potencial ahorro de recursos), sino que además tiene problemas de concurrencia.

Recomendamos que escribas tus singleton de la siguiente forma salvo que tengas un buen motivo en contrario:

  private static PseudoSingleton INSTANCE = new PseudoSingleton();

  public static PseudoSingleton getInstance() {
    return INSTANCE;
  }

Una explicación más detallada: https://www.geeksforgeeks.org/java-singleton-design-pattern-practices-examples/

¡Saludos!

[AlejandroDeheza]

Si si @gastonprieto, o sea que con la inyección del Singleton (o el PseudoSingleton) a los objetos correspondientes, se solucionaría ese problema

Lo que no entiendo bien es que, cuando quiero testear un Singleton (que tiene atributos y comportamiento que modifican esos atributos), no podria testear el comportamiento correctamente entre test y tests, creo.
Si no me equivoco, podria usar Mocks para testear como se relaciona con otros objetos, pero no se bien como testear lo que hay adentro del Singleton, sin romper todo jaja. Me refiero a mantener los test independientes, por eso se me ocurrió lo de generar nuevas instancias para cada test.

Si no, lo que se me ocurre, es inicializar al Singleton con sus atributos, probar los métodos del Singleton y destruir la instancia (creo que se puede) despues de cada test.
O si no, dejar el comportamiento del Singleton en otro objeto y solo dejar los atributos en el Singleton. Pero no se que tan bueno es eso de separar atributos y comportamiento.

[AlejandroDeheza]

ahhh, buenísimo! @flbulgarelli
lo voy a hacer de esa forma entonces.

Estaba viendo que parece interesante lo del Bill Pugh Singleton en ese link, voy a leer mas sobre eso despues también
Gracias!

[gastonprieto]

Buenas @AlejandroDeheza

Respondiendo un poco mas sobre el reseteo, podes tener un mensaje que te resetee el singleton (solo se usaría en los tests).

Y la otra es tal vez que un service locator, y cada vez que haces el before, pones un nuevo valor para esa dependencia