¿Hay algún valor en las propiedades de autoejecución de prueba de unidad?

Question

Parece excepcionalmente pesado, pero por la regla todo lo que esté disponible públicamente debe probarse ¿debe probarse auto-implemented properties?

clase de cliente

public class Customer 
{ 
    public string EmailAddr { get; set; } 
} 

probado por

[TestClass] 
public class CustomerTests : TestClassBase 
{ 
    [TestMethod] 
    public void CanSetCustomerEmailAddress() 
    { 
     //Arrange 
     Customer customer = new Customer(); 

     //Act 
     customer.EmailAddr = "foo@bar.com"; 

     //Assert 
     Assert.AreEqual("foo@bar.com", customer.EmailAddr); 
    } 
} 

Answer 1

¿Qué sucede si cambia de propiedades implementadas automáticamente a algo completamente diferente? La prueba solo parece redundante porque conoce la implementación, que no debe tener en cuenta al escribir pruebas.

Por supuesto, esto depende de la probabilidad de que realmente cambie la implementación en el corto plazo.

Answer 2

Depende si se está probando que una API se ajusta a un conjunto esperado de propiedades, o si, como demuestras , solo está probando el acceso y la configuración de las propiedades.

En el ejemplo que das Yo diría que no.

actualización

Conforme a la API de espera; si está accediendo a las propiedades de forma indirecta, por ejemplo, en un entorno de reflexión/dinámico, y utiliza las llamadas de acceso de propiedad y método para verificar que una API desconocida se ajusta a la esperada.

Answer 3

Generalmente considero que no vale la pena probar cualquier código que no esté realizando una acción. Esto generalmente significa que no pruebo las propiedades (implementadas automáticamente o no) porque solo están configurando o devolviendo un valor.

Esto cambiará si el captador o colocador de una propiedad realiza algún tipo de "trabajo", como posiblemente devolver uno de dos (o más) valores basados ​​en el estado de algún otro campo/propiedad/lo que sea.

Si no lo ha visto, le recomiendo Roy Osherove's . Aborda todo tipo de preguntas tipo "qué probar y cuándo", incluido este.

Answer 4

Las pruebas unitarias deben limitarse a la funcionalidad de prueba que está implementando en su aplicación.

No debe probar la API/SDK en la que se basa su aplicación. En parte porque es una pérdida de tiempo (¿su empresa quiere pagar por usted para probar el SDK/API de X-Third?), Y en parte porque introduce "ruido" en el conjunto de pruebas de su unidad. El contexto de la biblioteca de prueba de su unidad debe ser simplemente probar el código en su aplicación.

Answer 5

La configuración de prueba y las propiedades de obtención deben ocurrir en el contexto de probar una función comercial del objeto. Si no hay una función comercial que pruebe la propiedad, entonces no necesitó la propiedad o necesita más pruebas. Le sugiero que agregue las propiedades cuando agregue las pruebas que las necesitan en lugar de agregarlas antes de escribir las pruebas.

Al probar la función comercial, está tratando el código como una caja negra más desde la perspectiva de la prueba unitaria. Esto le permite cambiar los detalles de implementación por debajo con un impacto mucho menor en las pruebas.Como Refactor es una etapa importante (y con frecuencia pasada por alto) del ciclo TDD, esto significa mucha menos edición de código. También puede darse cuenta de que (por ejemplo) la propiedad no debe tener un organismo público y debe asignarse por un método que realice la validación y otra lógica comercial.