Así que veo que Assert tiene docenas de métodos que parecen hacer esencialmente lo mismo.¿Por qué la clase "Assert" tiene tantos métodos aparentemente redundantes? ¿Cuándo se debe usar cada uno?
Assert.IsFalse( a == b);
Assert.IsTrue( a != b);
Assert.AreNotEqual(a, b);
¿Por qué? ¿Es solo para ser más explícito? ¿Cuándo deberían usarse los diversos métodos? ¿Hay algún documento oficial de mejores prácticas?
La diferencia entre IsFalse y IsTrue es legibilidad. AreNotEqual permite que se presente un mensaje de error mejor cuando falla la prueba. IsTrue, por ejemplo, solo le dirá que se suponía que la respuesta era verdadera y que era realmente falsa. AreNotEqual mostrará los dos valores que se compararon en su mensaje de error.
Respuesta breve: Para facilitar la lectura.
respuesta Ligeramente más largo:
Sus pruebas son también de código, y en términos de intención son tan importantes como el código que está probando. Como tal, desea que el intento de la prueba sea lo más claro posible. A veces eso significa que usa IsFalse, a veces significa usar IsTrue.
"Usted [r] pruebas son también el código ... desea realizar el propósito de la prueba lo más claro posible" ... para jugar abogado del diablo: Entonces por qué no es una práctica estándar para crear y use isEqual, isNotEqual, etc. en el código normal? (Soy consciente de que Equals existe, pero se utiliza con menos frecuencia) – Catskul
@Catskul: la prueba tiene que ver con la capacidad de mantenimiento. Usamos == y! = Para la igualdad y la desigualdad en el código regular. ¿Con qué frecuencia ves: "if (a == (! B))" en lugar de "if (a! = B)"? –
@Reed, "! B" puede no tener ningún sentido. Afirma que AFAIK siempre debe reducirse a verdadero/falso. – Catskul
Esos tres métodos tienen tres objetivos diferentes y específicos. El objetivo de las pruebas es proporcionar una verificación y validación claras de su código. Al utilizar el método más claro y específico posible, está haciendo que su prueba sea la prueba más pequeña posible, con el significado más claro y específico posible.
Esto ayuda porque agrega claridad: puede ver, específicamente, qué se supone que debe hacer una prueba en una naturaleza más declarativa, donde usar el mismo método para múltiples escenarios de prueba, que cada uno tiene un significado diferente, requiere una mayor comprensión del código en sí, en lugar de la naturaleza de la prueba.
En este caso, el tercero es el (único) apropiado para usar. Sin embargo, si tuviera esta situación, tendrá que utilizar uno diferente, por ejemplo:
Assert.IsTrue(myClass.MethodThatReturnsTrue());
se debe utilizar el método que proporciona la mayor claridad en cuanto a su objetivo - si usted está comprobando dos valores para la igualdad , use Assert.IsEqual, si está verificando un booleano para verificar que es falso, use Assert.IsFalse. Esto hace que los informes de error sean significativos y comprensibles.
Ha afirmado (sin juego de palabras) que hacen cosas muy diferentes, pero no han ofrecido una explicación. – Catskul
@Catskul: volví a redactar: ¿eso ayuda? –
Hace que los errores sean más fáciles de leer; usa el que mejor se adapte a tu código.
En este caso, use # 3.
Porque puede sobrecargar el == y! =, Es por eso.
... y usted puede escribir su propio método Equals. AFAIK no está claro que estos métodos de Assert no se basen en esos operadores o en el método Equals para ese asunto. – Catskul
Se llama "Interfaz fluida" ... y hace que las cosas sean más legibles en opinión de muchos.
IMO, esta es la respuesta mejor/más concisa que he visto hasta ahora. Falta la respuesta principal que da un mensaje de error más informativo. – Catskul
Los marcos de afirmación fluida están aumentando en popularidad precisamente porque aumentan la legibilidad. Ver, por ejemplo, los emparejadores de Hamit de JUNit (http://code.google.com/p/hamcrest/wiki/Tutorial) y el modelo de restricción de NUnit (http://www.nunit.org/index.php?p=constraintModel&r=2.4 .1). –