Pruebas unitarias con entradas largas

Question

[TestMethod] 
public void SomeTestMethod() 
{ 
    string input = "some looooong input..."; 

    var proc = new Processor() 
    string result = proc.DoSomething(input); 

    Assert.Equals("good", result); 
} 

Si estoy escribiendo una prueba unitaria y tengo una entrada extremadamente larga (como transacciones EDI), ¿debería pegarla en mi método de prueba como una cadena larga?

Otros han sugerido que debería pegar esa cadena larga en un archivo y tratar ese archivo como un recurso incrustado en mi proyecto de prueba. Si hago algo así y necesito diferentes entradas para cada una de mis pruebas, podría ver una gran cantidad de archivos acumulándose y haciéndose difícil de mantener.

¿Existen mejores prácticas en torno a esto? ¿Debo seguir pegando estas largas cadenas en mis métodos de prueba?

Answer 1

Siempre pongo largas cadenas de prueba en los recursos, y mantengo nombres consistentes entre las pruebas y sus recursos para mantener el mapeo fácil. Uso el mismo nombre para el recurso y la prueba. Cuando necesito varios recursos para una prueba, agrego un sufijo 1, 2, 3, y así sucesivamente.

Answer 2

Si es algo rápido que no me importa, lo dejo caer en el código. Ya que es más que probable que pruebe un concepto.

Si su código se va a mantener como pruebas o código de producción, utilice un archivo de recursos como recurso incrustado o utilizando un archivo resx, con el que se sienta más cómodo.

Answer 3

Se puede utilizar un constructor de cadena diferente para crear una larga cadena de caracteres repetidos, como este:

string input = new string('x', 1024 * 1024/2); 

Este enfoque ofrece una forma mucho más elegante de crear cadenas largas EL PLAZO tener que pegar cadenas largas en tus pruebas.

Answer 4

Esto es solo una respuesta "obstinada" ya que nunca he visto ninguna mejor práctica al respecto;

Trabajo con archivos EDI y nuestros casos de prueba suelen contener datos de prueba pegados al igual que usted, en nuestro caso como constantes definidas fuera de la prueba para no saturar el código de prueba real.

Hemos encontrado que el manejo de archivos externos es propenso a errores en sí mismo.

Answer 5

Estaba probando algunos regexp que contra el archivo. Lo que hice fue copiar pegado el contenido del archivo en la clase de prueba como una propiedad normal, pero utilicé las etiquetas #region para ocultarlo. No necesito ver 200 líneas de texto cada vez que abro esa clase de prueba. Este es también uno de los pocos casos en los que me resulta útil la etiqueta #region.

Answer 6

Sin conocer el código Processor 's, tal como lo veo, Processor deben someterse a exámenes sencillo, rápido, unidad que cubren su funcionamiento interno, mientras que las pruebas como SomeTestMethod deben considerarse como prueba Integración.

Como tal, almacenaría todos mis datos de prueba en un archivo XML y lo cargaría en la prueba, ejecutando la misma prueba para cada entrada (si desea probar cantidades importantes de datos, puede usar una base de datos) . No es necesario escribir pruebas separadas para cada entrada.

Se describe un enfoque muy limpio y elegante sobre cómo se hace esto en MSTest here.