VB.NET y NUnit - TDD

Question

Estoy aprendiendo TDD con VB.NET y NUnit. Quiero saber qué es lo mejor que puedo hacer: usar muchos métodos de Assert dentro de un método de prueba o usar una afirmación por método?

Este es mi código. Gracias.

Imports NUnit.Framework 

<TestFixture()> _ 
Public Class CalculatorTest 
<Test()> _ 
Public Sub TestAdd() 
    Dim calculator As Calculator = New Calculator() 

    Assert.AreEqual(2, calculator.sum(1, 1)) 
    Assert.AreNotEqual(3, calculator.sum(2, 2)) 
    Assert.AreEqual(-1, calculator.sum(0, -1)) 
     Assert.AreNotEqual(3, calculator.sum(1, 1)) 
    End Sub 
End Class 

Answer 1

La 'Mejor práctica' generalmente aceptada es una afirmación por prueba. (Según Roy Osherove)

Sin embargo, esta prueba en particular puede hacerse un poco más simplemente con NUnit utilizando casos que sienta jurisprudencia:

<Test()> _ 
<TestCase(1, 1, 2)> _ 
<TestCase(1,-1, 0)> _ 
<TestCase(0,-1,-1)> _ 
Public Sub Calculator_Add_ReturnsExpectedResult(Integer a, Integer b, Integer expected) 
    Dim calculator As Calculator = New Calculator() 

    Assert.AreEqual(expected, calculator.sum(a, b)) 
End Class 

También tenga en cuenta el nombramiento utilicé allí, con el fin de aclarar exactamente lo que la prueba está probando

El principal detrás de la práctica "One Assert Per Test" es que desea que una prueba fallida signifique algo muy específico. Es decir, cada prueba debería decirle si algo específico está funcionando.

Answer 2

Este es un debate interesante, y puede ser una cuestión de estilo. Me gusta la opinión de Roy Osherove, que solo debería tener una afirmación por prueba unitaria.

Lea su análisis en profundidad de este tema here.

También, marque this fuera.

Answer 3

Una mejor manera de pensar es probar una cosa a la vez. Use tantas afirmaciones como sea necesario para probar una cosa, pero generalmente solo una. Las afirmaciones múltiples pueden ser una señal de que está probando más de una cosa a la vez, pero no es, en mi opinión, una regla difícil y rápida. La mejor guía es que no desea crear dependencias en sus pruebas entre conceptos que son independientes.

En su ejemplo, en realidad está probando 4 cosas, aunque probablemente solo necesite dos, ya que cubren el mismo terreno. Sugiero probar lo que sucede cuando se suman dos números positivos, dos negativos y uno negativo y uno positivo con resultados negativos y positivos. Luego pensaría en las propiedades matemáticas y la conmutatividad de prueba y la identidad aditiva (cero). Finalmente, probaría las condiciones de contorno: desbordamiento positivo y negativo, etc. Nota, esto puede o no ser exhaustivo, es decir, creo que he cubierto las bases, pero no estoy tratando demasiado de ser exhaustivo. ; Solo quiero ilustrar cómo piensas acerca de qué pruebas escribir y, sí, haría cada una de estas pruebas por separado con una sola afirmación.

Para algo más complejo, puede tener más de una afirmación que pruebe la misma "cosa"; por ejemplo, puede verificar si una fila está insertada correctamente en el DB con un conjunto dado de entradas. Creo que es perfectamente aceptable probar que todas las columnas tienen su valor adecuado en una sola prueba, en lugar de probar cada propiedad individualmente. Otros pueden diferir, pero no creo que en este caso esté creando dependencias al probar que todas las propiedades tienen sus valores correctos porque la inserción es una acción atómica.

Answer 4

La vista de Osherove huele a fundamentalismo. Por ejemplo, si una función devuelve una estructura/clase, tendrá que usar varias afirmaciones, o hacer una estructura personalizada que compare afirmar, que en realidad solo está haciendo lo mismo.

Lo importante es probar lo que hace la funcionalidad. Y tal vez para siempre preguntar "a los expertos".