Nunit: Adjuntar archivos al resultado de la prueba

El método que menciona es parte de la clase TestContext en el marco de prueba de Microsoft. NUnit también tiene una clase con el mismo nombre, pero no tiene relación con la clase MsTest y no tiene dicho método. NUnit no ofrece ninguna función para adjuntar archivos a la salida.

Gracias Charlie.
Pero, ¿se agregará el método AddResultFile a NUnit en el futuro?
Este método es realmente útil.

No hay ningún plan para ello en este momento. Si desea cambiar este problema por una solicitud de dicha función, podemos hacerlo y volver a abrirlo.

Si es así, debe explicar con más detalle cómo funcionaría. Cómo se crean los archivos, dónde se almacenan, etc. ¿Está pidiendo que NUnit realmente cree los archivos o simplemente retenga una referencia a ellos?

Por supuesto, tendríamos que aceptar la idea, priorizarla y programarla para algún lanzamiento.

Gracias por tu respuesta Charlie.
Sería genial si ese método se agregara a NUnit.
Funcionaría como el método AddResultFile de la clase TestContext en el marco de prueba de Microsoft.
algo como vincular el resultado de la prueba (archivo de resultado de la prueba html o captura de pantalla) a la salida de prueba en el Explorador de pruebas en VS. Puede ver la captura de pantalla como se muestra a continuación.

Gracias por la idea. Volveré a abrir esto.

Sin embargo, para ir más allá, tendríamos que averiguar cómo funciona para NUnit en sí, no solo para el adaptador. Estoy marcando esto como una Idea, que es lo que llamamos algo que no está lo suficientemente bien definido como para considerarlo como una característica futura. Quizás otras personas intervengan con sugerencias.

Cosas que debemos considerar:

• ¿Cómo se vería esto en el resultado XML?
• ¿Podemos empaquetar todo esto de alguna manera que el resultado y los archivos adjuntos se mantengan juntos?
• ¿Qué haría la consola NUnit con él, en todo caso?
• ¿La interfaz gráfica de usuario de NUnit lo mostraría de alguna manera?

Esta característica es imprescindible.
Estamos ejecutando nuestras pruebas de comportamiento automatizadas con NUnit y Selenium. Si una prueba falla, nos encanta adjuntar una captura de pantalla del navegador en el resultado de la prueba: esta es una gran ayuda para corregir la prueba.
Para hacer esto, tuvimos que usar el marco de prueba de Microsoft, pero no es tan poderoso como NUnit (atributo a nivel de ensamblaje o clase, clase de prueba genérica ...). Así que esperamos esta función en NUnit.

Estoy cambiando esto a una característica que necesita diseño, que es más sólida que una idea. Todavía tenemos que resolver las preguntas enumeradas en mi comentario anterior.

Supongo que está serializando el archivo en el xml o manteniendo un directorio referenciado a su lado. Uno conduce a un XML extenso, lentitud general y los archivos requieren un intérprete específico, el otro conduce a la posibilidad de que los archivos se separen de los resultados y las referencias se rompan.

¿Cuál es el menor de los males? Siento que con el primero, el dolor superará los beneficios de mantener todo en el paquete, y tener enlaces relativos 'con suerte disponibles' será suficiente.

• ¿Qué haría la consola NUnit con él, en todo caso?
• ¿La interfaz gráfica de usuario de NUnit lo mostraría de alguna manera?

Para la GUI, algo como la interfaz anterior se ve bastante bien, solo hipervínculos al archivo adjunto. La consola, en mi opinión, debería notificar al usuario en el mensaje de prueba fallida que un archivo está disponible y su ubicación.

Imagino que esto requerirá que alguien envíe un PR, una vez que se haya elaborado el diseño, @fredgate , ¿estás interesado? 😄

Deberíamos ver cómo MSTest almacena los archivos. Espero que la extensión de Visual Studio requiera un enlace al archivo en la unidad.

Parece que una referencia en XML es el camino a seguir. Para NUnit, la ubicación inicial lógica es el directorio de trabajo, que es donde va el XML de forma predeterminada. Eso resuelve mis dos primeros puntos anteriores.

Respondiendo a mis otros puntos:

• Supongo que la consola no haría más que enumerar los archivos adjuntos con la ruta, tal como lo hace con los resultados.
• La interfaz gráfica de usuario podría tener algún tipo de menú o panel para enumerar los archivos adjuntos. Podría mostrarlos siempre que se haya definido una aplicación predeterminada para el tipo de archivo en particular.

Parece una buena característica, que me inclinaría a elevar a la prioridad normal.

@rprouse ¿Recuerda cómo manejó Gallio los archivos adjuntos?

¿Qué debe incluir un elemento adjunto en términos de atributos y elementos? ¿Algo como esto?

<attachments>
    <attachment  description="Final screen shot">ScreenShot.jpg</attachment>
    ...
</attachments>

Supongo que es un hijo de la prueba que lo produjo, así que tenemos esa información. Los usuarios pueden querer incluir múltiples capturas de pantalla, de ahí la descripción. ¿Algo más?

¿Cuál es la sintaxis para adjuntar algo? ¿Deberíamos usar TestContext? ¿Debería haber una forma de asociarlo con una aserción para que el archivo adjunto se cree automáticamente en caso de falla?

¿Alguien quiere escribir una especificación para esto?

Parece una buena característica, que me inclinaría a elevar a la prioridad normal.

👍

@rprouse ¿Recuerda cómo manejó Gallio los archivos adjuntos?

No, nunca he usado archivos adjuntos. Me gusta tu formato XML. Personalmente, creo que deberíamos comenzar agregando archivos adjuntos desde TestContext, ya que es la ruta más simple. Luego podemos evaluar si queremos expandir eso a Afirma.

Entonces TestContext.CurrentContext.AddAttachment ?

Con sobrecargas por (string path) y (string path, string description) ?

¡Quizás ya tengamos una especificación!

Aumente la prioridad de esta función. Sería muy útil para nuestro resumen de resultados de prueba adjuntar capturas de pantalla de la interfaz de usuario. ¿Estarían estos archivos adjuntos disponibles en el resultado de la compilación dentro de VSTS (Visual Studio Team Services)?
Muchas gracias Charlie

Creo que es una buena característica y publicaré archivos adjuntos como artefactos de construcción en TeamCity.

Lo elevé a la prioridad normal ya que

Espero que nadie se haya olvidado de esto. Sería una característica muy útil.

Creo que los comentarios anteriores resolvieron todos los problemas de diseño, así que quitaré la etiqueta de diseño y agregaré el problema de implementación a Backlog.

No es tanto que hayamos olvidado esto, sino que tenemos una gran cantidad de cosas que suceden. Como mencioné en un comentario anterior, los elementos de prioridad normal como este no están programados como parte de nuestra planificación de lanzamiento. Depende de algún miembro del equipo o colaborador externo interesarse lo suficiente como para asumirlo. Con suerte, agregarlo a la cartera de pedidos motivará a alguien a dar un paso al frente. Dependiendo de tus habilidades, ¡podrías ser tú! 😄

gran característica! sería muy apreciado. ojalá alguien implemente esto pronto 😄

Acabo de hacer un PR para la funcionalidad de marco requerida para implementar esto, en # 2152. Dado que hay algunas personas que están rastreando este problema, planeo convertir este problema en un soporte para corredores de pista y Epic, una vez que decidamos qué hacer allí.

Estos son mis pensamientos:

Adaptador VS
Esta es una característica que tiene MSTest, por lo que el marco del adaptador VS ya tiene funcionalidad para mostrar archivos adjuntos. Solo necesito rastrear cómo conectar eso. 🙂

Consola / NUnitLite
Estoy en mentes encontradas aquí. Con las pruebas con errores / advertencias, tiene sentido mostrar la ruta de archivo / descripción de un archivo adjunto con el resultado. ¿Qué hay de los archivos adjuntos a las pruebas aprobadas? ¿Deberíamos tener una salida de 'Información' para mostrarlos? Entonces, los corredores de la consola tendrían tres tipos de salida: ¿Información / Advertencias / Errores?

GUI / Xamarin
Ambos deberían eventualmente respaldar esto, pero no creo que sea una prioridad alta. Crearé problemas, pero no los adjuntaré a este Epic; se pueden hacer cuando haya demanda / el tiempo lo permita.

TeamCity
@NikolayPianikov : dijiste que te interesaba esto. Quizás valga la pena rastrear el número 2152. 🙂

¿Pensamientos sobre todo lo anterior? @ nunit / framework-team? Haré problemas individuales una vez que hayamos decidido los próximos pasos.

@ChrisMaddock Los problemas también pueden ser problemas de diseño, por lo que puede hacer uno que diga "Descubra cómo admitir archivos adjuntos en la interfaz

Para el corredor de la consola, actualmente no mostramos todas las pruebas, aunque eso podría hacerse. Cualquier informe detallado puede ser manejado por una extensión o una transformación XSL personalizada. Esto último sería trivial de implementar para cualquier persona que esté dispuesta a hacer codificación XSL. 😄 Podría ser una transformación contribuida.

NUnitLite es complicado, ya que queremos que sea muy ligero. Sin embargo, se supone que los usuarios nombrarán sus archivos adjuntos de una manera inteligente y los pondrán todos en el mismo directorio, por lo que deberían ser bastante fáciles de encontrar. De hecho, eso también funciona para el corredor de la consola.
Creo que lo natural para la interfaz gráfica de usuario es mostrar el nombre y la descripción de los archivos adjuntos junto con todo lo demás sobre el resultado de la prueba. Podríamos convertirlo en un enlace si el usuario tiene instalada una aplicación adecuada que abrirá el archivo.

Una vez que tenemos los archivos adjuntos, creo que es muy fácil agregarlos a los resultados que pasamos a Visual Studio desde el adaptador.

Creé https://github.com/nunit/docs/issues/197 y https://github.com/nunit/nunit3-vs-adapter/issues/332 para cubrir los siguientes pasos.

Con respecto al soporte del corredor, si las únicas llamadas actuales para esto son la integración con el adaptador VS, me inclino a implementarlo allí, por ahora. Es una función que se adapta mejor a los corredores gráficos, luego a cli, y siempre se puede agregar otro soporte para corredores en el futuro, en caso de que las personas lo necesiten.

@ChrisMaddock Me encantaría ver el soporte de archivos adjuntos del corredor de la consola.

@kdubau - ¡momento perfecto! 😄 En ese caso, ¿cómo le gustaría que se viera? ¿Cuál sería tu caso de uso?

Podría imaginarme agregando un bloque de texto 'adjuntos' para probar fallas / advertencias, enumerando la descripción y la ruta del archivo. Una razón por la que estaba debatiendo no hacer esto, es que no estaba convencido de que muchos usuarios quisieran copiar / pegar una ruta de archivo fuera de su shell para encontrar el archivo respectivo. ¿Estarías en desacuerdo?

El otro problema en el que pensar es que la consola actualmente solo muestra pruebas fallidas / advertidas, y no todas las pruebas. ¿Deberíamos crear una tercera lista de resultados ('Información'?) Que muestre todas las pruebas aprobadas con archivos adjuntos?

Tal vez estaría bien que el corredor de la consola solo muestre los archivos adjuntos para las pruebas fallidas, ya que eso es posiblemente todo lo que es interesante en una ejecución de la consola. Me estoy imaginando archivos de registro relevantes para fallas aquí, y tal.

@kdubau En lugar de describirlo aquí, le sugiero que cree un nuevo problema en el repositorio nunit-console.

@ChrisMaddock @CharliePoole Podría haber entendido mal el contexto aquí. Solo me interesa que se haga referencia a los archivos adjuntos en el XML de salida; no es necesario mostrar realmente la información del archivo adjunto en la salida de la consola. Mi caso de uso es que mi sistema CI (Visual Studio Team Services) pueda cargar los archivos adjuntos enumerados en el XML como artefactos de compilación (por lo que solo necesitaría una referencia al archivo en el disco local).

Me preocupaba que la ejecución de pruebas a través del corredor de la consola no tuviera los archivos adjuntos en el XML, pero al leer más, no creo que esta sea la pregunta. Por favor corrígeme si estoy equivocado :)

@kdubau - Tienes razón. 🙂 # 2152 se acaba de fusionar, que admite archivos adjuntos en los resultados xml. Si todo va según lo planeado, será parte de NUnit 3.7, que se lanzará la próxima semana.

Bien ... si necesitamos "soporte" en la consola, eso significaría hacer algo más que simplemente guardar el XML que viene del framework. En el caso del adaptador nunit3, supongo que @ChrisMaddock está definiendo lo que eso significará.

Hola amigos, ¿este trabajo está terminado o más pendiente? No pude encontrar ningún problema abierto o relaciones públicas relacionadas con él.

Disculpas si me falta algo, pero mis archivos adjuntos de prueba aún no aparecen en VS Test Explorer como esperaba. Estoy usando NUnit3TestAdapter 3.8.0 de NuGet y la API TestContext.AddTestAttachement(file) pero no veo los archivos adjuntos en el Explorador de pruebas. Espero algo como esto:

¿Mis expectativas son incorrectas?

@kdubau : no, esto debería publicarse en NUnit v3.7 y NUnit3TestAdapter 3.8. Consulte https://github.com/nunit/nunit3-vs-adapter/issues/332 para conocer la implementación. Este problema permanece abierto ya que todavía no he podido agregar las dos oraciones de documentación requeridas ... 😱

Si no funciona, primero ejecutaría sus pruebas en la consola NUnit y vería si su archivo adjunto está registrado correctamente en el archivo xml de resultados. De lo contrario, abra un problema en este repositorio, si es así, abra un problema en el repositorio del adaptador y podremos investigar más a fondo. 🙂

@ChrisMaddock bien, problema creado https://github.com/nunit/nunit3-vs-adapter/issues/373

Gracias a la motivación de @kdubau , finalmente he documentado esta función y puedo cerrar este Epic. 😄