Pregunta

Tengo MUCHAS pruebas escritas para una pieza de software (que es una GRAN cosa) pero fue construida esencialmente como una prueba independiente en C #. Si bien esto funciona lo suficientemente bien, adolece de algunas deficiencias, entre las cuales se encuentra que no está utilizando un marco de prueba estándar y termina requiriendo que la persona que ejecuta la prueba comente las llamadas a las pruebas que no deberían ejecutarse (cuando no se desea ejecutar la prueba completa 'suite'). Me gustaría incorporarlo a mi proceso de prueba automatizado.

Vi que la Edición de prueba de VS 2008 tiene la noción de una 'Prueba genérica' que podría hacer lo que quiero, pero actualmente no estamos en condiciones de gastar el dinero en esa versión. Recientemente comencé a usar la versión VS 2008 Pro.

Estos métodos de prueba siguen un patrón familiar:

  • Realice alguna configuración para la prueba.
  • Ejecute la prueba.
  • Restablecer para la próxima prueba.

Cada uno de ellos devuelve un bool (pasar / fallar) y una cadena ref a una razón de falla, completada si falla.

En el lado positivo, al menos los métodos de prueba son consistentes.

Estoy sentado aquí esta noche contemplando el enfoque que podría adoptar mañana por la mañana para migrar todo este código de prueba a un marco de prueba y, francamente, no estoy tan entusiasmado con la idea de analizar más de 8-9K líneas de código de prueba a mano para hacer la conversión.

¿Ha tenido alguna experiencia emprendiendo tal conversión? ¿Tiene algún consejo? Creo que podría estar atrapado trabajando todo el tiempo haciendo búsquedas / reemplazos globales y cambiando las pruebas a mano.

¿Alguna idea?

¿Fue útil?

Solución

Si usa NUnit (que debería), deberá crear un nuevo método de prueba para cada uno de sus métodos de prueba actuales. NUnit usa la reflexión para consultar en la clase de prueba los métodos marcados con el atributo [Test] , que es cómo construye su lista de las pruebas que aparecen en la interfaz de usuario, y las clases de prueba usan NUnit < code> Assert para indicar si han pasado o fallado.

Me parece que si sus métodos de prueba son tan consistentes como usted dice, todos esos métodos de NUnit se verían así:

[Test]
public void MyTest()
{
   string msg;
   bool result = OldTestClass.MyTest(out msg);
   if (!result)
   {
      Console.WriteLine(msg);
   }
   Assert.AreEqual(result, true);

}

Una vez que haga que funcione, su próximo paso es escribir un programa que use la reflexión para obtener todos los nombres de métodos de prueba en su clase de prueba anterior y produzca un archivo .cs que tenga un método NUnit para cada uno de sus originales métodos de prueba.

Molesto, tal vez, pero no extremadamente doloroso. Y solo tendrá que hacerlo una vez.

Otros consejos

Estás a punto de vivir el idioma de "Una onza de prevención vale una libra de cura". Es especialmente cierto en la programación.

No mencionas NUnit (que creo que fue comprado por Microsoft para 2008, pero no me dejes llevar por eso). ¿Hay alguna razón especial por la que no utilizaste NUnit en primer lugar?

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top