Las clases y métodos estáticos son realmente difíciles de trabajar en las pruebas unitarias (que es una de las razones por las que trato de evitarlos). En este caso, probablemente desarrollaría un envoltorio alrededor de la clase estática, que contiene solo los métodos que uso. Luego utilizaría mi clase de contenedor en lugar de la clase real. La clase contenedora se construiría de modo que sea fácil de simular.
Ejemplo (tipo de) uso de RhinoMocks. Tenga en cuenta que utiliza la inyección de dependencia para dar a la clase bajo prueba una copia del contenedor. Si el contenedor proporcionado es nulo, crea uno.
public class MyClass
{
private VPU_Wrapper VPU { get; set; }
public MyClass() : this(null) {}
public MyClass(VPU_Wrapper vpu)
{
this.VPU = vpu ?? new VPU_Wrapper();
}
public string SomeMethod(string path)
{
return this.VPU.ToAbsolute(path);
}
}
public class VPU_Wrapper
{
public virtual string ToAbsolute(string path)
{
return VirtualPathUtility.ToAbsolute(path);
}
}
[TestMethod]
public void SomeTest()
{
string path = "~/path";
string expected = "/app/path";
var vpu = MockRepository.GenerateMock<VPU_Wrapper>();
vpu.Expect(v => v.ToAbsolute(path)).Return(expected);
MyClass class = new MyClass(vpu);
string actual = class.SomeMethod(path);
Assert.AreEqual(expected, actual);
vpu.VerifyAllExpectations();
}
+1 para envolverlo, que decía que yo prefiero declarar explícitamente una interfaz para la materia me burlaré de esa manera – eglasius
@Freddy - que a menudo utilizan una interfaz también. – tvanfosson