Nunit: Admite `dotnet test` en .NET CLI y .NET Core

Estábamos esperando que .NET Core se estabilizara un poco antes de avanzar con el n. ° 927, es por eso que no se ha actualizado con un nuevo título e información. Estaba planeando esperar cualquier anuncio que pueda aparecer en // build antes de seguir adelante, pero agradeceríamos cualquier ayuda que podamos obtener. Mi plan es comenzar a brindar un soporte más completo para más plataformas con la versión 3.4 este verano, incluidos .NET Core, UWP y Xamarin.

Ha proporcionado un resumen bien escrito aquí, por lo que cerraré el número 927 y usaré este problema para realizar un seguimiento en el futuro. Si desea ayudar con este problema, podemos coordinarnos, pero agradecería su ayuda.

El primer paso en este proceso fue crear un controlador / agente PCL que pueda cargar y ejecutar pruebas sin estar estrechamente vinculado a una versión específica de NUnit Framework como NUnitLite y el corredor Xamarin actual. Todavía está en su infancia, pero el trabajo en progreso está en el proyecto nunit.portable.agent .

También se agradecería cualquier ayuda o consejo que @piotrpMSFT o @livarcocc puedan dar: sonrisa:

@rprouse Tengo un error en la CLI para escribir una mejor documentación sobre las interacciones y los requisitos entre la prueba de dotnet y el corredor. Lo haré hoy o mañana y pondré un enlace aquí.

Este es el error que lo rastrea: https://github.com/dotnet/cli/issues/1803.

¿Cómo va esto? Me encantaría usar esto, y el ecosistema dotnet cli parece estar estabilizándose.

Estoy progresando, pero no quiero hacer demasiado hasta que caiga RC2. Me estoy cansando de intentar seguir el ritmo de los cambios: sonríe:

Se lanzó .NET Core RC2 y hay nueva información disponible. Enlaces para referencia.

• comando dotnet-test
• protocolo de comunicación dotnet-test

¿Puedo ayudar a alguno aquí? Este es un bloqueador para completar algunos de nuestros puertos como StackExchange.Redis.

@NickCraver Definitivamente me vendría bien un poco de ayuda, esa primera lectura del protocolo de comunicación no dejó las cosas terriblemente claras: sonríe:

Los primeros pasos son decidir cómo vamos a abordar esto. Actualmente tenemos la compilación portátil que apunta a .NET Core, pero es limitante. Estoy considerando crear una compilación central del marco, pero no estoy seguro de si lo necesito o debería.

Luego necesito ver lo que se necesita para crear una extensión de prueba para el comando dotnet .

Por último, me gustaría que el motor nunit pudiera iniciarse y comunicarse con un agente nunit central para que nunit3-console pueda ejecutar pruebas unitarias de .NET Core. He estado trabajando en esto, pero todavía tengo mucho trabajo por hacer allí.

¿Cómo le gustaría ayudar?

@rprouse Creo que tendrás que tener una compilación central para que posiblemente se pueda usar en varias plataformas, esa es una característica crítica.

No estoy seguro de cuánto tiempo podemos dedicar a esto en comparación con invertir en otro lugar, aunque para ser honesto, dada la cantidad de trabajo que queda. Por ahora, necesito sacar las bibliotecas por la puerta para muchas personas que esperan crear sus bibliotecas y aplicaciones. Odio decir esto, pero dado el retraso aquí frente a lo que está disponible hoy, creo que tendremos que terminar de trasladar todo a xUnit, de lo contrario, cientos o miles de desarrolladores están esperando una cadena bloqueada de lanzamientos aquí.

Intentaré volver a visitar esto después de que estemos estables y el tiempo lo permita, pero (y corríjame si me equivoco) en este momento estamos hablando de semanas de trabajo que quedan (según su publicación) antes de que yo ' Podría usar esto para ejecutar lo que espero sean puertos de biblioteca terminados y listos para enviar. Desde el punto de vista del deber de autor, primero necesito desbloquear a las personas que están conmigo y luego ayudar en la parte superior como pueda.

@NickCraver en lugar de gastar el esfuerzo en la migración a xUnit, podría ser más fácil crear un corredor NUnitLite de línea de comandos para ejecutar sus pruebas de .NET Core. No es una solución perfecta, pero posiblemente la menor cantidad de trabajo. Está un poco desactualizado, pero escribí en un blog sobre cómo hacerlo en Testing .NET Core usando NUnit 3 .

Lo hago así para algunos proyectos personales y es funcional.

Me complacerá ayudarlo a obtener una compilación adecuada de dotnet-test-nunit. Estoy seguro de que mucha gente se beneficiaría. Gran parte del contrato definido en el protocolo ya está implementado en una biblioteca auxiliar. Si tenemos un corredor xplat nunit en funcionamiento, esto debería ser poco trabajo.

¿Sería útil dividir esto en dos fases: una especie de lanzamiento "rápido y sucio, puede tener trucos cutres, pero al menos saquemos algo" y luego una integración más completa más adelante?

(El solo hecho de estar a punto de crear las pruebas con un TFM de netstandard1.3 ayudaría mucho a desbloquearme para Noda Time, por ejemplo).

@jskeet y @NickCraver puedes usar NUnit hoy a través del "truco" de NUnitlite como sugirió

@roji : Eso funcionó con dnxcore50 (lo he estado usando con Noda Time por un tiempo), pero usando netstandard1.3 , las dependencias en NUnit y NUnitLite no son válidas.

@jskeet mi proyecto de prueba apunta a netcoreapp1.0 y depende de Nunit + NUnitLite 3.2.1. Tengo "imports" : [ "dotnet54" ] y funciona como un encanto ...

@roji : Gracias por eso ... cruzar los dedos ...

@roji : Todavía tengo problemas para ejecutar las pruebas. ¿Podrías enlazar dónde estás haciendo esto en tu proyecto de prueba, como un ejemplo a seguir?

@jskeet seguro, aquí tienes: https://github.com/npgsql/npgsql/tree/dev/test/Npgsql.Tests

@jskeet, las importaciones también deberían funcionar para usted. RC2 cambia algunas cosas, así que reescribiré mi publicación de blog sobre cómo probar con NUnit 3 con RC2 en mente y publicaré el código en GitHub. Agregaré un enlace aquí cuando esté listo, con suerte esta mañana (EST).

@piotrpMSFT, ¿ puedes dotnet-test-nunit ? Puedo buscar, pero estoy persiguiendo varias cosas en este momento, por lo que se agradecería su ayuda. Estoy seguro de que tú también estás ocupado, así que si no lo tienes a mano, no pierdas tiempo en él, lo encontraré.

He publicado una publicación de blog actualizada Testing .NET Core RC2 Using NUnit 3 para cualquiera que esté interesado.

@jskeet , necesita la declaración de importaciones en su proyecto.json. Se agrega de forma predeterminada en las nuevas plantillas de .NET Core, pero debe agregarse al actualizar.

Para project.json en un corredor de consola;

  "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }

O en una asamblea;

  "frameworks": {
    "netstandard1.5": {
      "imports": "dnxcore50"
    }

Al actualizar a RC2, tener cosas antiguas de DNX en mi camino también me mordió. Algo para comprobar.

@rprouse : Gracias; Ahora puedo compilar y las pruebas se ejecutan en Windows. En Linux, veo una "Referencia de objeto no configurada para una instancia de un objeto". mensaje en dotnet run , que necesito investigar más. Probaré su muestra mínima para ver si tiene el mismo problema ...

@jskeet , estamos usando este enfoque tanto en Windows como en Linux sin problemas. Vea aquí y aquí para ver ejemplos.

@oschwald : Sí, parece que el problema con la "Referencia de objeto no establecida ..." es un problema muy separado con las dependencias. Es una pena que el mensaje de error sea tan inútil (sin siquiera un seguimiento de la pila), lo estoy investigando.

@jskeet Hay algunas causas, ¿es tuya? https://github.com/dotnet/cli/issues/3075

@NickCraver : No, he realizado una restauración de dotnet con éxito.

En mi caso, tengo un archivo project.json que funciona sin depender de otro proyecto, pero falla. Necesito dedicar un poco más de tiempo a crear una reproducción completa.

@jskeet Gotcha - relevante: https://github.com/dotnet/cli/issues/2469 y el canal de Slack es excelente para project.json depuración en vivo, ingrese con ejemplos y, por lo general, puede comenzar bastante rápido. Para Slack, los canales #general y # dotnet-core son bastante activos, muchas personas pasan por esto y ayudan a la siguiente persona.

Hmm ... y ahora está funcionando. Es posible que _fue_ el mismo problema que reportó @NickCraver , y que estaba dotnet restore -ing con el proyecto equivocado para solucionarlo. De todos modos, ahora estoy ejecutando pruebas de Noda Time en Linux, así que yay :) Gracias a todos.

@piotrpMSFT re mi solicitud de punteros, encontré todo lo que necesitaba y comencé a trabajar.

He agregado un PR inicial para el corredor dotnet-test-nunit en nunit / dotnet-test-nunit # 1

Explora y ejecuta pruebas, pero aún necesita algo de trabajo, limpieza y pruebas. Haré que el feed de NuGet para los artefactos de compilación sea más accesible si alguien quiere jugar con él.

Si alguien tiene ideas sobre cómo puedo depurar el paquete NuGet cuando Visual Studio lo carga, me vendría bien un poco de ayuda. Hasta ahora, no se está ejecutando en Visual Studio, pero eso podría ser un problema de configuración.

@rprouse : Me alegraría ver cómo lo

Todavía no está listo para el horario de máxima audiencia, pero tengo pruebas de NUnit .NET Core ejecutándose en la consola y en Visual Studio. Todavía quedan varios problemas por resolver antes de obtener una versión alfa, pero ahora estamos mucho más cerca, ya que el trabajo duro está hecho y todo se reduce a los detalles.

Publicaré detalles sobre cómo probar con la compilación de CI después de solucionar algunos problemas. Agradecería que la gente pudiera patear los neumáticos y ayudarme a encontrar problemas.

Aquí hay una captura de pantalla.

@rprouse : ¿Algún progreso en la construcción de CI? Definitivamente dispuesto a patear los neumáticos; Noda Time utiliza una cantidad _razonable_ de funciones de NUnit, por lo que debería ser un buen comienzo, de todos modos. Tengo muchas ganas de poder ejecutar pruebas en VS nuevamente. (Espero que NCrunch y CodeRush para Roslyn también comiencen a admitirlo una vez que esté disponible ...)

@jskeet y otros que están interesados ​​en patear los neumáticos y ayudarme a probar antes de lanzar un alfa, he actualizado mi repositorio de demostración en una rama dotnet-test-nunit para usar el nuevo corredor dotnet-test-nunit .

Informe los problemas en el repositorio nunit / dotnet-test-nunit .

Las instrucciones de alto nivel son;

Actualización: dotnet-test-nunit ahora está disponible como alfa en NuGet, seleccione Include prereleases . Ya no necesita actualizar su archivo nuget.config .

dotnet-test-nunit aún está en desarrollo, por lo que deberá agregar un archivo NuGet.Config a su solución para descargar paquetes NuGet de las fuentes NUnit CI NuGet.

Su project.json en su proyecto de prueba debería tener el siguiente aspecto;

project.json

{
    "version": "1.0.0-*",

    "dependencies": {
        "NUnitWithDotNetCoreRC2": "1.0.0-*",
        "NETStandard.Library": "1.5.0-rc2-24027",
        "NUnit": "3.2.1",
        "dotnet-test-nunit": "3.4.0-alpha-1"
    },
    "testRunner": "nunit",

    "frameworks": {
        "netstandard1.5": {
            "imports": [
                "dnxcore50",
                "netcoreapp1.0",
                "portable-net45+win8"
            ]
        }
    },

    "runtimes": {
        "win10-x86": { },
        "win10-x64": { }
    }
}

Las líneas de interés aquí son la dependencia de dotnet-test-nunit . Siéntase libre de usar la versión preliminar más reciente que termina en -CI , que es la última de la rama maestra. Tenga en cuenta que la dependencia NUnitWithDotNetCoreRC2 es el proyecto bajo prueba.

He añadido "testRunner": "nunit" para especificar NUnit 3 como el adaptador de prueba. También tuve que agregar a las importaciones para que se resolvieran tanto el adaptador de prueba como NUnit. Por último, tuve que agregar runtimes . Si alguien puede explicar por qué necesito hacer eso, hágamelo saber.

Ahora puede ejecutar sus pruebas con el Explorador de pruebas de Visual Studio o ejecutando dotnet test desde la línea de comandos.

# Restore the NuGet packages
dotnet restore

# Run the unit tests in the current directory
dotnet test

# Run the unit tests in a different directory
dotnet test .\test\NUnitWithDotNetCoreRC2.Test\

Advertencia

Como dije, esto todavía está en desarrollo. dotnet-test-nunit versión 3.3.0.39-CI enumerada anteriormente tiene un error en el que arrojará un ArgumentException cuando intente guardar el archivo TestResult.xml .

También tenga en cuenta que la línea de comando dotnet traga líneas en blanco y no funciona con el color. La salida del corredor de prueba NUnit está en color, pero no la verá.

La parte de "tragar línea en blanco" es un error conocido: https://github.com/dotnet/cli/issues/2234

Gracias por el enlace @jskeet , parece que el color también es un error conocido, dotnet / cli # 1977

El ArgumentException se ha corregido en 3.3.0.49-CI . Actualizaré mis instrucciones anteriores con la solución. Otro problema pendiente es que actualmente no estoy proporcionando el número de línea para las pruebas al corredor, por lo que hacer clic en las pruebas en el Explorador de pruebas de Visual Studio no lo llevará al código.

¿Estoy en lo cierto al decir que todavía no hay soporte para argumentos de línea de comando, como --where etc.? (Entiendo completamente que son los primeros días, solo estoy tratando de verificar si esto es algo que debería poder hacer).

He probado un project.json ligeramente diferente al tuyo. Lo he incluido a continuación textualmente, pero las diferencias importantes son:

• También quiero probar el tiempo de ejecución del escritorio, así que tengo dos objetivos de marco
• Estoy usando netcoreapp1.0 lugar de netstandard1.5
• He incluido la dependencia Microsoft.NETCore.App , con "type"="platform"
• Mira mamá, no hay sección de tiempo de ejecución. (Posiblemente debido a algunos de los cambios anteriores ...)

{
  "buildOptions": {
    "keyFile": "../../NodaTime Release.snk",
    "embed": {
      "include":  [   
        "TestData/*"
      ]
    }
  },

  "configurations": {
    "Debug": {
      "buildOptions": {
        "define": [ "DEBUG", "TRACE" ]
      }
    },
    "Release": {
      "buildOptions": {
        "define": [ "RELEASE", "TRACE" ],
        "optimize": true
      }
    }
  },

  "dependencies": {
    "NodaTime": { "target": "project" },
    "NodaTime.Testing": { "target": "project" },
    "NUnit": "3.2.1",
    "dotnet-test-nunit": "3.3.0.49-CI",
    "Microsoft.CSharp": "4.0.1-rc2-24027",
    "System.Dynamic.Runtime": "4.0.11-rc2-24027",
    "System.Reflection.Extensions": "4.0.1-rc2-24027",
    "System.Xml.XDocument": "4.0.11-rc2-24027"
  },

  "testRunner": "nunit",

  "frameworks": {
    "net451": {
      "frameworkAssemblies": {
        "System.Runtime": "",
        "System.Threading.Tasks": "",
        "System.Xml.Linq": ""
      }
    },
    "netcoreapp1.0": {
      "imports" : [ "dnxcore50", "netcoreapp1.0", "portable-net45+win8" ],
      "buildOptions": {
        "define": [ "PCL" ]
      },
      "dependencies": {
        "Microsoft.NETCore.App": { 
          "version": "1.0.0-rc2-3002702",
          "type": "platform"
        },
        "System.Console": "4.0.0-rc2-24027",
      }
    }
  }
}

Resultado:

Test Count: 15141, Passed: 15141, Failed: 0, Inconclusive: 0, Skipped: 0

Woot. (Usando net451 obtengo un recuento de prueba de 15646, que es lo que esperaría).

A continuación: intentar lo mismo en una máquina Linux (donde su project.json presumiblemente no funcionaría sin modificaciones ya que no menciona Linux, pero el mío debería, en teoría; habiendo dicho eso, es una máquina Ubuntu 16.04, por lo que es dotnet CLI está un poco agrupada).

Mmm. Las pruebas en Linux no habían terminado después de 14 minutos de consumir el 100% de la CPU. Tendrá que mirar más de cerca lo que está sucediendo allí.

@jskeet

¿Estoy en lo cierto al decir que todavía no hay soporte para argumentos de línea de comandos, como, en dónde, etc.?

Mal probado, pero he conectado --where y la mayoría de los parámetros comunes de la línea de comandos. Todavía tengo un problema, nunit / dotnet-test-nunit # 4 para verificar que todos estén conectados correctamente y funcionen, y agregue los que falten. Hasta ahora, no he probado muchos, pero he usado algunos agregándolos al final del comando dotnet . Sin embargo, todavía necesito averiguar exactamente cómo funciona. Por ejemplo, la opción de línea de comando --debug funcionaba bien desde la solución dotnet-test-nunit , pero arroja dotnet-test Error: 0 : Microsoft.DotNet.Cli.Utils.CommandUnknownException: No executable found matching command "dotnet-test-" cuando la ejecuto desde mi solución de prueba. Tampoco tengo idea de cómo encadenar la línea de comando de ayuda a la nuestra para mostrar qué es compatible.

Mientras tanto, puede echar un vistazo a https://github.com/nunit/dotnet-test-nunit/blob/master/src/dotnet-test-nunit/CommandLineOptions.cs para ver qué opciones de línea de comando creo que son apoyado: sonrisa:

Ah, sí, parece que dotnet test no tiene la misma facilidad que dotnet run para separar los argumentos del marco de prueba de los argumentos a dotnet test . He estado intentando

dotnet test -- --help

y

dotnet test -- --where=cat!=Slow

Solo usando

dotnet test --where=cat!=Slow

funciona bien. Presentará una solicitud de función para eso; es bueno poder ser completamente inequívoco.

Hacer clic en las pruebas y navegar hasta el código ahora está fijo en 3.3.0.60-CI .

Todavía hay dos problemas de alta prioridad, luego estoy planeando hacer una versión alfa, momento en el que cerraré este problema y realizaré un seguimiento de todo en el nuevo repositorio. Los dos problemas son;

• [x] nunit / dotnet-test-nunit # 22 Agregar mensajes y rastros de pila a pruebas fallidas
• [x] nunit / dotnet-test-nunit # 12 TestContext.WriteLine no aparece en el resumen de la prueba TestExplorer

Solo como un FYI, realicé las pruebas de Noda Time nuevamente hoy en mi caja de Ubuntu, y se completaron después de unos 15 minutos. Parece que todos están funcionando 5-6 veces más lento en mi Linux i5 que en mi Win10 i7. Sin embargo, no estoy seguro de cuánto tiene que ver eso con la CPU y cuánto tiene que ver con JIT, y definitivamente está fuera del alcance de NUnit :)

@jskeet gracias por la actualización, eso es una buena noticia. ¿Necesitaba enlaces mono para las pruebas de Linux como se indica en nunit / dotnet-test-nunit # 9?

Para cualquiera que esté probando, el último paquete bueno de NuGet es 3.3.0.69-CI , pruebe con eso. Ahora no hay ningún problema pendiente que creo que sea lo suficientemente serio como para bloquear un lanzamiento. Si no se informa ninguno esta semana, es probable que cree una versión alfa a finales de esta semana o principios de la próxima. Una vez que haga eso, cerraré este problema y las discusiones / problemas futuros pueden continuar en el repositorio dotnet-test-nunit .

Prueba ahora o para siempre calla: sonríe:

@rprouse : No he intentado ejecutarlo en Mono, solo .NET Core en Linux. Eso funcionó bien con el project.json exacto anterior.

Dará un giro a 69-CI ...

Una diferencia que he notado entre esto y el corredor de la aplicación de consola es que la versión "dotnet test" parece incluir el tiempo dedicado a buscar pruebas en la duración total, mientras que el comando "dotnet run" que solía usar con NUnitLite no lo hacía. . En Noda Time, esto significa que si ejecuto con --where=cat==Foo (no hay tales pruebas en esa categoría), "dotnet test" informa una duración de 14s, mientras que "dotnet run" informa una duración de 0.01s - a pesar de ambos tomando aproximadamente el mismo tiempo real transcurrido.

¿Es esto deliberado? Ciertamente no me importa el comportamiento, pero puede valer la pena señalarlo en algún lugar para evitar que la gente piense que en realidad es más lento.

@jskeet esa es una buena observación, de hecho es el caso. Debido a que no tenemos el motor NUnit completo para ejecutar las pruebas, el código es más simplista, pero es posible que pueda iniciar el reloj en el primer evento de inicio de la prueba en lugar de terminar la ejecución de la prueba. Ingresaré un problema.

Lancé una versión alfa de dotnet-test-nunit en GitHub en https://www.nuget.org/packages/dotnet-test-nunit/3.4.0-alpha-1 , por lo que ya no necesita cambiar su NuGet.config file y use versiones de CI.

Ahora que tengo una salida alfa, voy a cerrar este problema. Ayúdame a probar el alfa e informar cualquier problema en https://github.com/nunit/dotnet-test-nunit/issues. Está previsto que el lanzamiento final salga a fin de mes con el lanzamiento de NUnit 3.4. Publicaré versiones alfa y beta actualizadas en función de los problemas encontrados.

He actualizado la documentación en el archivo Léame por dotnet-test-nunit . Lo mantendré actualizado.

https://github.com/nunit/dotnet-test-nunit

Como señalé antes, no necesita especificar los tiempos de ejecución si usa "type": "platform" para la dependencia "Microsoft.NETCore.App" . Dados los documentos de xUnit, creo que este es el enfoque preferido.

Actualmente tengo una solicitud de extracción que se ejecuta a través de Travis; si se vuelve verde, Noda Time dependerá de esto, por lo que debería darle un uso _alguno_. Bien hecho, señor ...

Una desventaja que he notado hace un momento: esto significa que ya no puedo probar fácilmente con Mono en Linux. Creo que no es un problema de NUnit, es básicamente una manifestación de https://github.com/dotnet/cli/issues/3073 pero de NUnit. Todavía tengo la esperanza de que se arregle eventualmente; por el momento voy a deshabilitar mis pruebas mono en Travis, con un poco de desgana. ( dotnet test definitivamente es el futuro).