¿Qué pruebas hacer para este pequeño método?

Question

Actualmente tengo el siguiente método:

public void SetNewRandomValue() { 
    double newValue = numberGenerator.GenerateDouble(
          genesValuesInterval.MinimumValue, 
          genesValuesInterval.MaximumValue 
          ); 

    this.value = newValue; 
} 

cuáles deberían ser las directrices para decidir el número de pruebas (y que pone a prueba) para hacer que este método? Actualmente he hecho la siguiente (sólo después de la realización del procedimiento - es decir, no se prueba primero):

var interval = new Interval(-10, 10); 
var numberGeneratorMock = new Mock<INumberGenerator>(MockBehavior.Strict); 
var numberGenerator = numberGeneratorMock.Object; 

double expectedValue = 5.0; 

numberGeneratorMock.Setup(ng => 
     ng.GenerateDouble(interval.MinimumValue, interval.MaximumValue)) 
     .Returns(expectedValue); 

var gene = new Gene(numberGenerator, 0, new Interval(-10, 10)); 
gene.SetNewRandomValue(); 

Assert.AreEqual<double>(expectedValue, gene.Value); 

que, básicamente, sólo pone a prueba una situación. Regression-testingwise Diría que no puedo pensar en una forma de alterar el código, convirtiéndolo en código de mal funcionamiento y aún así tener el pase de prueba, es decir, creo que el método se ve decentemente cubierto.

¿Cuál es su opinión al respecto? ¿Cómo manejarías este pequeño método?

Gracias

Answer 1

que examinaría la cobertura de código con cualquier herramienta de prueba que utilice, si una cobertura de código está disponible para su marco de pruebas.

Personalmente me gusta trabajar con Microsoft Testing Tool o NUnit Testing Framework. Luego puedo hacer clic con el botón derecho en mi proyecto de pruebas y Test with NCover (mientras uso NUnit), que ejecutará las pruebas y me dirá el porcentaje de código cubierto para cada uno de mis objetos y pruebas.

Digo que cuando haya terminado de verificar la cobertura del código que resultaría de al menos un 98% de cobertura del código, es probable que su código sea probado.

Answer 2

Recomendaría echar un vistazo a Pex - realmente puede ayudar a generar el tipo de pruebas de unidad que está buscando (es decir, descubrir las diferentes rutas posibles y los resultados dados un método y un valor de retorno).

Answer 3

Esa prueba se ve bien. Lo único que puede afirmar sobre SetNewRandomValue es que el miembro Value se asigna posteriormente. Has burlado la llamada al GenerateDouble y verificado que Value contiene el número esperado, por lo que deberías estar bien.

Answer 4

Definitivamente podría hacer un caso para que la unidad no lo pruebe. En mi humilde opinión, la inspección del código es una metodología de prueba perfectamente válida. Por lo general, no prueba elementos como los generadores de propiedades/getters, creo que este método es lo suficientemente simple como para evitar las pruebas unitarias por la misma razón.

Dicho esto, si realmente quieres probarlo, esto es lo que haría: lo probaría con un par de valores, no solo una vez con 5. (SetNewRandomValue podría implementarse como this.value = 5;, que no debería pase.) Lo probaría con un número no entero, para confirmar que no hay un molde extraño para enteros allí.

Puede probar que llama a GenerateDouble con los parámetros adecuados, aunque eso realmente está probando un detalle de implementación. (SetNewRandomValue podría implementarse como numberGenerator.GenerateDouble(0, interval.max - interval.min) + interval.min;, y eso no debería fallar en la prueba). Puede usar un generador de números aleatorios reales, y hacer SetNewRandomValue unas miles de veces, y probar que los valores se distribuyan uniformemente dentro de su rango esperado.

Answer 5

Para responder cómo probarlo, debería ser capaz de describir cuál es el comportamiento deseado.

En cuanto a su código, supongo que se supone que "Gene.SetNewRandomValue" establece self.Value en un número que se encuentra dentro del intervalo pasado al constructor.

No estoy muy familiarizado con la clase Mock, por lo que es posible que no esté en la base, pero parece que no está probando eso. ¿Qué pasa si su implementación tiene este error tipográfico?

double newValue = numberGenerator.GenerateDouble( 
         genesValuesInterval.MinimumValue, 
         genesValuesInterval.MinimumValue 
         ); 

¿No pasaría aún su prueba?

Answer 6

También puede escribir una prueba de documento (y verificar) el comportamiento esperado de Gene.SetNewRandomValue cuando NumberGenerator.GenerateDouble devuelve un valor fuera del intervalo especificado.

Answer 7

El método está haciendo tres cosas:
Calling numberGenerator.GenerateDouble con genesValuesInterval.MinimumValue como primer parámetro,
y con genesValuesInterval.MaximumValue como segundo parámetro,
y el establecimiento de this.value al resultado de esa llamada.

Su prueba prueba la tercera de estas cosas, pero no las dos primeras. Podría escribir dos pruebas más que verifiquen que se invoque el simulacro con los parámetros primero y segundo correctos.

Edit (responder a los comentarios más abajo): Si el comportamiento previsto de este método es para establecer this.value a un doble al azar dentro de un intervalo especificado anteriormente, a continuación, las tres pruebas anteriores son útiles (suponiendo genesValuesInterval min y max son los previamente rango especificado y que tiene pruebas establecidas para afirmar que numberGenerator.GenerateDouble (min, max) devuelve un doble dentro del rango especificado

Si el comportamiento previsto de este método es simplemente establecer this.value en un doble aleatorio dentro de (Double.MinValue, Double.MaxValue), entonces las dos primeras pruebas son innecesarias ya que esto es solo un detalle de implementación.

Si el