Unit Testing show output

Busqué la herramienta de pruebas unitarias y encontré la adecuada es NUnit y creo que es buena pero mi problema es que esta herramienta solo muestra el resultado del método de prueba solo (pase o no) y necesito mostrar no solo pase o falle también la salida. ¿Cómo puedo mostrar la salida usando NUnit o si hay otra herramienta de prueba de la unidad también es buena? Si no es compatible, sugiérame cómo puedo solucionarlo.Unit Testing show output

Todas las ideas son bienvenidas

Fuente

2011-03-14 Mohammed Thabet

En la barra inferior de NUnit puede hacer clic en la salida de texto y que muestra todos los resultados de la depuración y la consola.

Fuente

2011-03-14 18:33:43

bien cuando llamo método getEmp (10) se volverá objeto emplyee con nombre y apellido y el trabajo y la edad y .... todos sus members.That de que necesito –

puede utilizar System.Diagnostics. Debug.Write o System.Console.WriteLine para escribir en la salida de NUnit Text con la información que considere necesaria. –

¿Puedo obtener propiedades del objeto devuelto porque no conozco el objeto? Necesito imprimir todas las propiedades dentro del objeto (empleado o empresa o ...) –

Canalizar la salida de System.Console funcionará para NUnit, pero no es su mejor opción.

Para pasar las pruebas, no debería necesitar revisar la salida de la consola para verificar que las pruebas hayan pasado. Si lo estás, lo estás haciendo mal. Las pruebas deben ser automáticas y repetibles sin intervención humana. La verificación manual no escala y crea falsos positivos.

Por otro lado, tener una salida de consola para las pruebas fallidas es útil, pero solo proporcionará información que de otro modo podría inferirse al adjuntar un depurador. Es un gran esfuerzo adicional agregar el registro de la consola a su aplicación para obtener un pequeño beneficio.

En cambio, asegúrese de que sus mensajes de error sean significativos. Al escribir sus pruebas, asegúrese de que sus afirmaciones sean explícitas. Siempre trate de usar la afirmación que se ajusta estrechamente al objeto que está afirmando y proporcione un mensaje de falla que explique por qué la prueba es importante.

Por ejemplo:

// very bad 
Assert.IsTrue(collection.Count == 23);

La afirmación anterior no proporcionan realmente mucha ayuda cuando la prueba falla. A medida que NUnit formatea el resultado de las aserciones, esta afirmación no le ayudará, ya que indicará algo así como "esperando <True> pero fue <False>".

Una afirmación más apropiada proporcionará fallas de prueba más significativas.

// much better 
Assert.AreEqual(23, collection.Count, 
       "There should be a minimum of 23 items by default.");

Esto proporciona un mensaje de fallo mucho más significativo: "Esperando < 23> pero fue < 0>:. Debe haber un mínimo de 23 elementos por defecto"

Fuente

2011-03-15 14:18:17 bryanbcook

Después de ver su respuesta, me pregunto si entendí mal, ¿quiere la salida que produce en su código o la salida de la prueba? Simplemente dice la salida, así que puede haber asumido la salida en general. –

Pensé que era producción general, también. Mi punto es que si tiene que confiar en el resultado general porque pasar/no es suficiente, debe reconsiderar su enfoque de prueba. – bryanbcook

No, necesito mi salida, no de salida general. Eres correcto, Jesús, y trato de probarlo –

depende de dónde estás querer dar salida a los datos de una prueba. Creo que mencionaste algo más de la salida File, Log, Console, Debug. Como alternativa NUnit permite dar salida a mensaje en el flujo de salida de las pruebas regulares, sólo tiene que utilizar siguientes métodos de utilidad:

Para prueba exitosa

Assert.Pass(string message, object[] parms);

Para prueba fallida

Assert.Fail(string message, object[] parms);

Más detalles ver here

Fuente

2011-07-15 18:12:33 sll

Estos métodos finalizan la prueba. –

Esta publicación es muy larga después de que se hizo la pregunta, pero quería e en.Sí, puede lograr mucho en las pruebas de unidad/integración y probablemente haga la mayor parte de lo que necesita. Entonces, estoy de acuerdo, haz todo lo que puedas en tus métodos de prueba.

Pero a veces, proporcionar alguna salida es útil. Especialmente si necesita verificar los resultados y esa verificación no se puede realizar a través de su prueba unitaria. Piense en un sistema externo que su entorno de desarrollo/prueba no tiene o tiene acceso limitado.

Como ejemplo, digamos que está presionando un webapi para CREAR un reclamo y la respuesta es el nuevo número de reclamo. Pero la API no expone los métodos para OBTENER un reclamo, y necesita verificar algunos otros datos que se crearon cuando realizó la llamada webapi. En este caso, puede usar los números de reclamo emitidos para verificar manualmente el sistema remoto.

Fwiw

Fuente

2016-11-04 23:05:43 Kershaw

Respuesta

Cuestiones relacionadas