Tomando tu ejemplo (con un poco de refactorización),
assert(a + b, math.add(a, b));
no ayuda a:
- entender cómo se
math.addcomporta internamente
- Sepa lo que sucederá con los casos límite.
Es casi como decir:
- Si desea saber qué hace el método, vaya y vea los cientos de líneas de código fuente usted mismo (porque, sí,
math.add puede contener cientos de LOC; consulte a continuación).
- No me molesto en saber si el método funciona correctamente. Está bien si los valores esperados y reales son diferentes de lo que realmente esperaba .
Esto también significa que no tiene que agregar pruebas como:
assert(3, math.add(1, 2));
assert(4, math.add(2, 2));
Tampoco ayudan, o al menos, una vez que hizo la primera afirmación, la segunda no aporta nada útil.
En cambio, ¿qué pasa con:
const numeric Pi = 3.1415926535897932384626433832795;
const numeric Expected = 4.1415926535897932384626433832795;
assert(Expected, math.add(Pi, 1),
"Adding an integer to a long numeric doesn't give a long numeric result.");
assert(Expected, math.add(1, Pi),
"Adding a long numeric to an integer doesn't give a long numeric result.");
Esto se explica por sí mismo y es muy útil tanto para usted como para la persona que mantendrá el código fuente más adelante. Imagine que esta persona realiza una ligera modificación para math.addsimplificar el código y optimizar el rendimiento, y ve el resultado de la prueba como:
Test TestNumeric() failed on assertion 2, line 5: Adding a long numeric to an
integer doesn't give a long numeric result.
Expected value: 4.1415926535897932384626433832795
Actual value: 4
esta persona comprenderá de inmediato que el método recién modificado depende del orden de los argumentos: si el primer argumento es un número entero y el segundo es un número largo, el resultado sería un número entero, mientras que se esperaba un número largo.
Del mismo modo, obtener el valor real de 4.141592en la primera afirmación se explica por sí mismo: usted sabe que se espera que el método tenga una gran precisión , pero en realidad falla.
Por la misma razón, dos afirmaciones siguientes pueden tener sentido en algunos idiomas:
// We don't expect a concatenation. `math` library is not intended for this.
assert(0, math.add("Hello", "World"));
// We expect the method to convert every string as if it was a decimal.
assert(5, math.add("0x2F", 5));
Además, ¿qué pasa con:
assert(numeric.Infinity, math.add(numeric.Infinity, 1));
También se explica por sí mismo: desea que su método pueda manejar correctamente el infinito. Ir más allá del infinito o lanzar una excepción no es un comportamiento esperado.
¿O tal vez, dependiendo de tu idioma, esto tendrá más sentido?
/**
* Ensures that when adding numbers which exceed the maximum value, the method
* fails with OverflowException, instead of restarting at numeric.Minimum + 1.
*/
TestOverflow()
{
UnitTest.ExpectException(ofType(OverflowException));
numeric result = math.add(numeric.Maximum, 1));
UnitTest.Fail("The tested code succeeded, while an OverflowException was
expected.");
}
How does unit testing work?Nadie sabe realmente :)