A mi modo de ver, ambos tienen la ventaja y están en una "desventaja" (sic).
La ventaja es que tiene un sistema con el que se siente cómodo y que funciona para usted. Está contento de que confirme la validez de su producto, y probablemente no encuentre ningún valor comercial al intentar cambiar todas sus pruebas para algo que use un marco diferente. Si puede refactorizar su código y sus pruebas recogen los cambios, o mejor aún, si puede modificar sus pruebas y su código existente no pasa las pruebas hasta que se refactorice, entonces tendrá todas sus bases cubiertas. Sin embargo...
Una de las ventajas de tener una API de prueba de unidad bien diseñada es que hay una gran cantidad de soporte nativo en la mayoría de los IDE modernos. Esto no afectará a los usuarios de VI y emacs de núcleo duro que se burlan de los usuarios de Visual Studio, pero para aquellos que usan un buen IDE, tienen la capacidad de depurar sus pruebas y ejecutarlas dentro El IDE mismo. Esto es bueno, sin embargo, hay una ventaja aún mayor dependiendo del marco que use, y eso está en el lenguaje utilizado para probar su código.
Cuando digo lenguaje , no estoy hablando de un lenguaje de programación, sino que estoy hablando de un conjunto de palabras enriquecidas envueltas en una sintaxis fluida que hace que el código de prueba se lea como una historia. En particular, me he convertido en un defensor del uso de los marcos BDD . Mi API favorita de DotNet BDD es StoryQ, pero hay varios otros con el mismo propósito básico, que es sacar un concepto de un documento de requisitos y escribirlo en código de forma similar a como está escrito en la especificación. Sin embargo, las API realmente buenas van aún más lejos, interceptando cada declaración individual dentro de una prueba e indicando si esa declaración se ejecutó con éxito o falló. Esto es increíblemente útil, ya que puede ver toda la prueba ejecutada sin regresar antes, lo que significa que sus esfuerzos de depuración se vuelven increíblemente eficientes, ya que solo necesita enfocar su atención en las partes de la prueba que fallaron, sin necesidad de decodificar toda la llamada secuencia. La otra cosa buena es que el resultado de la prueba muestra toda esta información,
Como ejemplo de lo que estoy hablando, compare lo siguiente:
Usando afirmaciones:
Assert(variable_A == expected_value_1); // if this fails...
Assert(variable_B == expected_value_2); // ...this will not execute
Assert(variable_C == expected_value_3); // ...and nor will this!
Usando una API BDD fluida:
(Imagine que los bits en cursiva son básicamente punteros de método)
WithScenario("Test Scenario")
.Given(*AConfiguration*) // each method
.When(*MyMethodToTestIsCalledWith*, variable_A, variable_B, variable_C) // in the
.Then(*ExpectVariableAEquals*, expected_value_1) // Scenario will
.And(*ExpectVariableBEquals*, expected_value_2) // indicate if it has
.And(*ExpectVariableCEquals*, expected_value_3) // passed or failed execution.
.Execute();
Ahora que la sintaxis BDD es más larga y más amplia, y estos ejemplos son terriblemente artificiales, sin embargo, para situaciones de prueba muy complejas en las que muchas cosas están cambiando en un sistema como resultado de un comportamiento determinado del sistema, la sintaxis BDD le ofrece una clara descripción sobre lo que está probando y cómo se ha definido su configuración de prueba, y puede mostrar este código a un no programador y ellos comprenderán instantáneamente lo que está sucediendo. Además, si "variable_A" falla la prueba en ambos casos, el ejemplo Asserts no se ejecutará más allá de la primera afirmación hasta que haya solucionado el problema, mientras que la API de BDD ejecutará todos los métodos llamados en la cadena, a su vez, e indicará qué partes individuales de la declaración estaban en error.
Personalmente, creo que este enfoque funciona mucho mejor que los marcos de xUnit más tradicionales en el sentido de que el lenguaje de prueba es el mismo lenguaje que sus clientes hablarán de sus requisitos lógicos. Aun así, me las arreglé para usar los marcos xUnit en un estilo similar sin necesidad de inventar una API de prueba completa para respaldar mis esfuerzos, y aunque las afirmaciones aún se cortocircuitarán, leerán más limpiamente. Por ejemplo:
Usando Nunit :
[Test]
void TestMyMethod()
{
const int theExpectedValue = someValue;
GivenASetupToTestMyMethod();
var theActualValue = WhenIExecuteMyMethodToTest();
Assert.That(theActualValue, Is.EqualTo(theExpectedValue)); // nice, but it's not BDD
}
Si decide explorar utilizando una API de prueba unitaria, mi consejo es experimentar con un gran número de API diferentes durante un tiempo, y mantener una actitud abierta sobre su enfoque. Si bien defiendo personalmente BDD, sus propias necesidades comerciales pueden requerir algo diferente para las circunstancias de su equipo. Sin embargo, la clave es evitar adivinar su sistema existente. Siempre puede admitir sus pruebas existentes con algunas pruebas usando otra API si es necesario, pero ciertamente no recomendaría una gran reescritura de prueba solo para hacer que todo sea igual. A medida que el código heredado deja de usarse, puede reemplazarlo fácilmente y sus pruebas con un código nuevo, y pruebas usando una API alternativa, y esto sin necesidad de invertir en un esfuerzo importante que no necesariamente le dará ningún valor comercial real. En cuanto al uso de una API de prueba unitaria,