2010-09-23 12 views
10

estoy aprendiendo prueba Unidad VS y probado este:Prueba de unidad de Visual Studio: ¿por qué la prueba no es concluyente mientras que prueba los mismos valores de flotación?

[TestMethod()] 
    public void calcTest() 
    { 
     double expected = 1.234F; // TODO: Initialize to an appropriate value 
     double actual; 
     actual = 1.234F; 
     Assert.AreEqual(expected, actual); 
     Assert.Inconclusive("Verify the correctness of this test method."); 
    } 

Cuando se ejecuta este método de ensayo, se dice concluyentes ??? Por qué ?

Actualización: Hola chicos, está bien decir que no se comparan las carrozas, pero los requisitos empresariales son lo que son, entonces, ¿qué debo hacer si necesito compararlos?

¿Quiere decir que es imposible probar el cálculo flotante sin dolor de cabeza? Entonces, si las pruebas son un dolor de cabeza en el cálculo financiero, ¿no es mejor no hacer ninguna prueba?

parece un enorme error o defecto de diseño en el marco de pruebas en lugar vs :) como se dice aquí http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.assert.inconclusive%28VS.80%29.aspx

Indica que una afirmación no puede ser probada verdadera o falsa.

¡Ya que comparo 2 artículos idénticos seguro que es verdad!

+1

El conjunto de pruebas Unidad de Microsoft ahora también incluye métodos sobrecargados para probar los flotadores (y dobles) mediante introducción de una tolerancia delta que dice "qué iguales" deben pasar los valores (http://msdn.microsoft.com/en-us/library/ms243456.aspx). Usado como este: 'Assert.AreEqual (flotante esperado, flotación real, flotante delta, cadena que fallaTestMessage)' – Spiralis

Respuesta

17

¿erm, porque le dijiste que fuera?

Assert.Inconclusive("Verify the correctness of this test method."); 

Ahora usted tiene su AreEqual, usted debería ser capaz de eliminar esta Inconclusive

Cualquier fallo durante una prueba (sin incluir excepciones que usted maneja intencionalmente) es generalmente terminal, pero cualquier afirman que pasa (como el AreEqual aquí) simplemente sigue funcionando. Entonces, la primera prueba pasa, luego la última línea la señala como inconclusa.

+0

¿Por qué Assert.Conclusive no existe? No estamos haciendo pruebas estadísticas donde tal Inconclusión sería sensible, esta es una prueba determinista donde el resultado de la prueba será sí o no. – user310291

+0

Creo que tienes razón, pero la plantilla no debe poner esto como predeterminado en el fragmento de código porque es muy confuso. – user310291

+1

@ user310291 desde una perspectiva de prueba, esto no es confuso. Todas las pruebas fallan hasta que se escribe la prueba correcta (y se elimina la parte no concluyente) o se arregla el código que se va a probar. –

2

¿No significa que pasó el AreEqual, lo que significa que se llama Assert.Inconclusive, lo que conduce a un resultado no concluyente?

De the docs:

similares a fallar en la que indica una afirmación no es concluyente y sin comprobar cualquier condición.

Si no desea que el resultado sea incluyente, retire la llamada a Assert.Inconclusive :)

+0

Mi punto es matemáticamente y desde el punto de vista del negocio es seguro no concluyente pero concluyente, ya que es cierto :) – user310291

+0

Assert.Inconclusive Method Indica que una afirmación no se puede probar como verdadera o falsa. – user310291

+0

de acuerdo con http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.assert.inconclusive%28VS.80%29.aspx – user310291

8

Incluso cuando se ha eliminado el Assert.Inconclusive todavía podría tener problemas.

que está probando la igualdad de dos números de coma flotante y en general con los valores calculados que no se consigue ellas exactamente lo mismo. Debe verificar que el valor real se encuentre dentro de un rango aceptable del valor esperado:

Math.Abs(actual - expected) < 0.00001; 

por ejemplo.

Su Assert.AreEqual(expected, actual); funciona en este caso porque está asignando el mismo valor a ambas variables.

+1

Buena advertencia, pero en este caso está comparando dos variables inicializado a partir de literales, por lo que * esperaría * que esté bien. ¡Pero +1, definitivamente es un buen punto para subir! –

+0

@Marc - Vi eso, así que agregué una nota a ese efecto. – ChrisF

+0

El hecho de que las representaciones exactas de coma flotante pueden no existir para ciertos números decimales no los hace 'difusos'. El punto general sobre no comparar 2 flotantes para la igualdad está bien, pero no se aplica en este caso: no hay ninguna razón para que el compilador elija diferentes representaciones 'dobles' para el * mismo *' flotante' literal. – Ani

2

La prueba automática UnitTest es generada por VS y le indica que cree algunas operaciones para comparar. si comenta el último comando de Assert obtendrá "Passed" con marca verde, pero no lo probó.
Necesita, como en el comentario, "Inicializar a un valor apropiado" y como en el último Assert "Verificar la corrección de este método de prueba".
Inicialice los valores esperados y reales de donde proceden de por ejemplo, se espera que sea el valor esperado de la función Agregar (x, y) donde x = 2 e y = 3. El valor real debe provenir de la función. en este caso:

// Sample - Start 
Expected = 2+3; 
Actual = Add(2,3); 
Assert.AreEqual(expected, actual); 
// Sample - End 

espero que ayudó, me rompió algunos dientes para que ... ;-)

Cuestiones relacionadas