clase/método/propiedad estática en la prueba de unidad, detenerlo o no

Question

actualización deben utilizar una clase/método/propiedad estática en un entorno de desarrollo de prueba de unidad, dado que se trata de ninguna manera de probarlo

sin introducir una envoltura que de nuevo no sea comprobable?

Otro escenario es que cuando los miembros estáticos se usan dentro del objetivo probado de la unidad, el memeber estático no se puede burlar. Por lo tanto, debe probar los miembros estáticos cuando se prueba el objetivo probado de la unidad. Desea aislarlo cuando el miembro estático realiza el cálculo.

Answer 1

método estático Prueba no es diferente de probar cualquier otro método Tener método estático como una dependenciadentro de otro módulo de prueba plantea problemas (.. ya que se ha mencionado - no se puede burlarse/ramal con herramientas libres) Pero si el método estático en sí está unidad de prueba puede simplemente treat it as working, reliable component

en general, no hay nada malo (como en, que no interrumpa.. unidad de prueba/TDD) con métodos estáticos cuando:

• es simple, método de entrada-salida (todo tipo de "calcular este dado que")
• es fiable, por lo que entendemos que es o unidad probada por usted o proviene de fuente de tercera parte se considera fiable (p.ej. Math.Floor podría considerarse confiable; su uso no debería aumentar "¡Cuidado, es estático!" advertencia; uno podría suponer que Microsoft hace su trabajo)

¿Cuándo los métodos estáticos causarán problemas y deberían evitarse?Básicamente sólo cuando interactúan con/hacer algo que no puede controlar (o simulado):

• todo tipo de sistema de archivos, bases de datos, dependencias de red
• otros métodos estáticos (posiblemente más complejos) llamaron desde el interior
• casi cualquier cosa que su marco de burla no puede hacer frente en condiciones regulares

Editar:dos ejemplos de cuándo método estático se hacer pruebas unitarias dura

public int ExtractSumFromReport(string reportPath) 
{ 
    var reportFile = File.ReadAllText(reportPath); 
    // ... 
} 

¿Cómo hacer frente a File.ReadAllText? Obviamente, esto irá al sistema de archivos para recuperar el contenido del archivo, que es el principal no-no cuando se prueban las unidades. Este es un ejemplo de método estático con dependencia externa. Para evitar eso, normalmente se crea un wrapper alrededor de la API del sistema de archivos o simplemente se inyecta como dependencia/delegado.

public void SaveUser(User user) 
{ 
    var session = SessionFactory.CreateSession(); 
    // ... 
} 

¿Y esto? La sesión es dependencia no trivial. Claro, podría venir como ISession, pero ¿cómo fuerza SessionFactory para volver a simular? No podemos. Y no podemos crear fácil de detectar el objeto de sesión tampoco.

En casos como el anterior, es mejor evitar por completo los métodos estáticos.

Answer 2

No puede simular métodos/propiedades estáticos. Por lo tanto, cuando su classA usa algún miembro estático de classB, no puede probar classA de forma aislada.

ACTUALIZACIÓN: No veo ningún problema de envolver una clase estática en el objeto. No lleva mucho tiempo, pero le permite disminuir el acoplamiento en su sistema.

Answer 3

Métodos estáticos CAN ser probado unidad. Que no puede ser burlado (por lo general, hay algunos marcos de hacer esto como Moles

Answer 4

Técnicamente usted puede burlarse del método estático en Java con PowerMock, pero si necesita hacer esto, seriamente recomiendo refactorizar su código. Creo que los métodos estáticos siempre deben ser private y usarse solo dentro de las clases en las que están definidos, para fines internos. Considero el método estático expuesto públicamente como a code smell.