Cómo crear pruebas para objetos poco

Question

Soy nuevo en burlarse/probar y quiero saber a qué nivel debe ir cuando realice la prueba. Por ejemplo, en mi código tengo el siguiente objeto:

public class RuleViolation 
{ 
    public string ErrorMessage { get; private set; } 
    public string PropertyName { get; private set; } 

    public RuleViolation(string errorMessage) 
    { 
     ErrorMessage = errorMessage; 
    } 

    public RuleViolation(string errorMessage, string propertyName) 
    { 
     ErrorMessage = errorMessage; 
     PropertyName = propertyName; 
    } 
} 

Este es un objeto relativamente simple. Entonces mi pregunta es:

¿Necesita una prueba de unidad?

Si lo hace, ¿qué pruebo y cómo?

Gracias

Answer 1

no diría probablemente. La única cosa que es probable que desea verificar si es extremadamente importante son los modificadores de acceso:

public string ErrorMessage { get; private set; } 
public string PropertyName { get; private set; } 

Si es realmente muy importante que el código fuera de la clase no puede modificar los que podría ser la única cosa que me gustaría probar y verificar

Aquí es cómo puede obtener los descriptores de acceso en una propiedad:

class Program 
    { 
     static void Main(string[] args) 
     { 
      var property = typeof(Test).GetProperty("Accessor"); 

      var methods = property.GetAccessors(); 
     } 
    } 



    public class Test 
    { 
     public string Accessor 
     { 

      get; 
      private set; 
     }  

    } 

Con la property.GetAccessors();

Puede ver si el colocador está allí. Si lo es, entonces el colocador es público. (También hay propiedades IsPrivate e IsPublic que puede usar para verificar también los otros Accesores).

Answer 2

que no contiene ninguna lógica => Nada que comprobar

Answer 3

Aunque sea simple, hay lógica en sus constructores. Me gustaría probar que:

RuleViolation ruleViolation = new RuleViolation("This is the error message"); 
Assert.AreEqual("This is the error message", ruleViolation.ErrorMessage); 
Assert.IsEmpty(ruleViolation.PropertyName); 

RuleViolation ruleViolation = new RuleViolation("This is the error message", "ThisIsMyProperty"); 
Assert.AreEqual("This is the error message", ruleViolation.ErrorMessage); 
Assert.AreEqual("ThisIsMyProperty", ruleViolation.PropertyName); 

Answer 4

Usted podía unidad de prueba de este objeto, pero es tan simple como para no requerir la misma. La prueba sería algo así como (NUnit ejemplo)

[Test] 
public void TestRuleViolationConstructorWithErrorMessageParameterSetsErrorMessageProperty() { 
    // Arrange 
    var errorMessage = "An error message"; 

    // Act 
    var ruleViolation = new RuleViolation(errorMessage); 

    // Assert 
    Assert.AreEqual(errorMessage, ruleViolation.ErrorMessage); 
} 

Hay poco valor a pruebas de escritura como estos, sin embargo, ya se está probando que las propiedades del marco .NET funcionan correctamente. En general, puede confiar en que Microsoft lo hizo bien :-)

En cuanto a la burla, esto es útil cuando su clase bajo prueba tiene una dependencia, tal vez en otra clase en su propia aplicación, o en un tipo de un marco. Los marcos de burla te permiten llamar a métodos y propiedades sobre la dependencia sin tener que preocuparte por crear la dependencia concretamente en el código y, en cambio, permitirte inyectar valores definidos para las propiedades, devolver valores para los métodos, etc. Moq es un marco excelente y prueba para una clase básica, con dependencia sería algo como esto:

[Test] 
public void TestCalculateReturnsBasicRateTaxForMiddleIncome() { 
    // Arrange 
    // TaxPolicy is a dependency that we need to manipulate. 
    var policy = new Mock<TaxPolicy>(); 
    bar.Setup(x => x.BasicRate.Returns(0.22d)); 

    var taxCalculator = new TaxCalculator(); 

    // Act 
    // Calculate takes a TaxPolicy and an annual income. 
    var result = taxCalculator.Calculate(policy.Object, 25000); 

    // Assert 
    // Basic Rate tax is 22%, which is 5500 of 25000. 
    Assert.AreEqual(5500, result); 
} 

TaxPolicy habría unidad probada en su propio aparato para verificar que se comporta correctamente. Aquí, queremos probar que el TaxCalculator funciona correctamente, por lo que nos burlamos del objeto TaxPolicy para simplificar nuestras pruebas; Al hacerlo, podemos especificar el comportamiento de solo los bits de TaxPolicy en los que estamos interesados. Sin él, necesitaríamos crear mocks/stubs/fakes enrollados a mano, o crear instancias reales de TaxPolicy para pasar.

Sin embargo, hay más en Moq que esto; echa un vistazo a quick-start tutorial para ver más de lo que puede hacer.

Answer 5

Si fuera mi código y mi objeto, tendría pruebas para él, no importa cuán simple o complicada sea la clase, punto. Incluso si parece improbable que la clase se rompa, las pruebas son dónde, OMI, documenta sus suposiciones, decisiones de diseño y uso adecuado.

Al hacerlo, no solo valida que lo que tiene funciona según lo previsto, sino que tiene la oportunidad de pensar en escenarios típicos (¿qué ocurre si los parametros del ctor son nulos o vacíos o tienen espacios en blanco al final? es el PropertyName opcional en una clase inmutable?).

Y si los requisitos IF (¿cuándo?) Cambian, tiene un punto de partida sólido para abordar eso. Y SI esta clase trivial de alguna manera no interactúa muy bien con todas las otras clases, puede tener una prueba para detectar eso antes que sus clientes.

Es la forma correcta de diseñar su código.

HTH,
Berryl