El desarrollo basado en pruebas significa que deja de codificar cuando pasan todas sus pruebas.
Si no tiene una prueba para una propiedad, ¿por qué debería implementarla? Si no prueba / define el comportamiento esperado en caso de una asignación "ilegal", ¿qué debe hacer la propiedad?
Por lo tanto, estoy totalmente a favor de probar cada comportamiento que una clase debería exhibir. Incluidas las propiedades "primitivas".
Para facilitar esta prueba, creé un NUnit simple TestFixture
que proporciona puntos de extensión para establecer / obtener el valor y toma listas de valores válidos e inválidos y tiene una sola prueba para verificar si la propiedad funciona correctamente. Probar una sola propiedad podría verse así:
[TestFixture]
public class Test_MyObject_SomeProperty : PropertyTest<int>
{
private MyObject obj = null;
public override void SetUp() { obj = new MyObject(); }
public override void TearDown() { obj = null; }
public override int Get() { return obj.SomeProperty; }
public override Set(int value) { obj.SomeProperty = value; }
public override IEnumerable<int> SomeValidValues() { return new List() { 1,3,5,7 }; }
public override IEnumerable<int> SomeInvalidValues() { return new List() { 2,4,6 }; }
}
Usando lambdas y atributos, esto podría incluso escribirse de manera más compacta. Tengo entendido que MBUnit tiene incluso algo de soporte nativo para cosas como esa. Sin embargo, el punto es que el código anterior captura la intención de la propiedad.
PD: Probablemente PropertyTest también debería tener una forma de verificar que otras propiedades en el objeto no hayan cambiado. Hmm ... de vuelta a la mesa de dibujo.