Singletons para facilar pruebas unitarias en una base de código heredada. Una buena idea o no?

Question

Gente, Tengo una gran base de código .Net heredada, y estoy tratando de introducir Pruebas unitarias para el equipo. Son buenos chicos, pero esto es nuevo para ellos (para ser honesto, es razonablemente nuevo para mí también).

Uno de los problemas es que la base de código hace un uso intensivo de las clases estáticas en System.IO, existen extensas bibliotecas internas de clases estáticas y las clases no se escriben en las interfaces (a menos que haya un motivo de diseño real para hacerlo asi que).

Estoy desarrollando una estrategia fácil con NUnit y FakeItEasy.

Para abordar las dependencias de clase estáticas, he escrito una herramienta que genera clases de envoltura e interfaces para clases estáticas existentes. p.ej. En un archivo de configuración digo que quiero envoltorios para System.IO Directory & File, la herramienta genera un ensamblado con código a lo largo de las líneas de. . .

public interface IFile 
{ 
    // All Method signatures taken from System.IO.File 
} 

internal class File 
    : IFile 
{ 
    // All Methods delegate to System.IO.File 
} 

public interface IIO 
{ 
    IFile File {get;} 
    IDirectory Directory {get;} 
} 

internal class IO 
    : IIO 
{ 
    public IFile File {get; private set;} 
    public IDirectory Directory {get; private set;} 
    public IO() 
    { 
     File = new File(); 
     Directory = new Directory(); 
    } 
} 


public static class IO 
{ 
    public IIO Instance {get; set;} 
    static IO() 
    { 
     Instance = new IO(); 
    } 
} 

La idea es que en la base de código existente puede ser simplemente actualiza por una búsqueda/reemplazo y la adición de un nuevo proyecto de referencia, y que en las pruebas de unidad se puede asignar un objeto a Mock IO.Instance.

Por una parte, estoy bastante satisfecho con este enfoque, nos da una forma clara y rápida de dejar de usar clases estáticas directamente, además nos da una forma de burlar esas clases estáticas y nos permite probar el código que depende de ellos.

Por otro lado, creo que he hecho un trato con el diablo, he reemplazado dependencias en singleton implícitos con dependencias en singletons explícitos.

¿Todo esto va a ir terriblemente mal para mí en algún momento en el futuro cercano, o cree que este es un enfoque viable?

Answer 1

Haría como lo hizo para una aplicación heredada. No hay mucho que pueda hacer sin tener que refaccionar piezas más grandes. Todavía es flexible ya que puede cambiar la implementación a través de la clase estática.

Una idea podría ser hacer que el método de instancia sea estático y registrar la clase IO en su IOC en su lugar (como singleton). Luego permita que el COI encuentre la implementación correcta (que es devuelta por el método de Instancia estática).

buena introducción a los contenedores IoC: http://joelabrahamsson.com/entry/inversion-of-control-introduction-with-examples-in-dotnet