Nunit: Поддержка dotnet test в .NET CLI и .NET Core

Мы ждали, пока .NET Core немного успокоится, прежде чем перейти к # 927, поэтому он не был обновлен с новым названием и информацией. Я планировал дождаться любых объявлений, которые могут появиться на // build, прежде чем двигаться дальше, но мы были бы признательны за любую помощь, которую мы можем получить. Я планирую начать этим летом с выпуском 3.4 более полную поддержку большего числа платформ, включая .NET Core, UWP и Xamarin.

Вы предоставили здесь хорошо написанное резюме, поэтому я собираюсь закрыть № 927 и использовать эту проблему для отслеживания в будущем. Если вы хотите помочь с этим вопросом, мы можем координировать свои действия, но я был бы рад вашей помощи.

Первым шагом в этом процессе было создание драйвера / агента PCL, который может загружать и выполнять тесты, не будучи жестко привязанным к определенной версии NUnit Framework, такой как NUnitLite и текущий бегун Xamarin. Он все еще находится в зачаточном состоянии, но работа над ним ведется в проекте

Любая помощь или совет, которые могут дать @piotrpMSFT или @livarcocc , также будут оценены: smile:

@rprouse У меня есть ошибка в интерфейсе командной строки, чтобы написать лучшую документацию, касающуюся взаимодействия и требований между тестом dotnet и бегуном. Сделаю сегодня-завтра и выложу здесь ссылку.

Это отслеживание ошибок: https://github.com/dotnet/cli/issues/1803.

Как дела? Я хотел бы использовать это, и экосистема dotnet cli, похоже, стабилизируется.

У меня есть некоторые успехи, но я не хочу делать слишком много, пока RC2 не упадет. Меня уже тошнит от попыток угнаться за изменениями: smile:

Выпущен .NET Core RC2, доступна новая информация. Ссылки для справки.

• команда dotnet-test
• протокол связи dotnet-test

Я могу чем-нибудь здесь помочь? Это блокировщик некоторых наших портов, таких как StackExchange.Redis.

@NickCraver Мне определенно

Первые шаги решают, как мы собираемся к этому подойти. В настоящее время у нас есть переносимая сборка, предназначенная для .NET Core, но она ограничивает. Я подумываю о создании базовой сборки фреймворка, но не уверен, нужно ли мне это или нужно.

Затем мне нужно посмотреть, что нужно для создания тестового расширения для команды dotnet .

Наконец, я хотел бы, чтобы движок nunit мог запускаться и взаимодействовать с основным агентом nunit-agent, чтобы консоль nunit3 могла запускать модульные тесты .NET Core. Я работал над этим, но мне еще предстоит много работы.

Как бы вы хотели помочь?

@rprouse Я думаю, вам

Я не уверен, сколько времени мы можем потратить на это по сравнению с инвестированием в другие места, хотя, честно говоря, учитывая объем оставшейся работы. На данный момент мне нужно выпустить библиотеки для многих нижестоящих людей, ожидающих создания своих библиотек и приложений. Мне неприятно это говорить, но, учитывая отставание здесь от того, что доступно сегодня, я думаю, что нам придется закончить перенос всего на xUnit, иначе сотни и тысячи разработчиков ждут здесь заблокированной цепочки выпусков.

Я постараюсь снова посетить это, когда мы стабилизируемся и позволит время, но (и поправьте меня, если я ошибаюсь) в данный момент мы говорим о неделях работы, оставшейся (по вашему сообщению), прежде чем я ' Я смогу использовать это для запуска того, что, я надеюсь, уже готово к отправке библиотечных портов. С точки зрения авторского долга, мне нужно сначала разблокировать людей на себе, а затем помогать апстриму, чем могу.

@NickCraver вместо того, чтобы тратить усилия на перенос на xUnit, может быть проще создать средство запуска NUnitLite из командной строки для запуска тестов .NET Core. Это не идеальное решение, но, возможно, требует минимального объема работы. Это немного устарело, но я писал в блоге о том, как это сделать, на Testing .NET Core с помощью NUnit 3 .

Я делаю это для нескольких личных проектов, и это работает.

Я был бы рад помочь с получением правильной сборки dotnet-test-nunit. Я уверен, что многим это принесет пользу. Большая часть контракта, определенного в протоколе, уже реализована во вспомогательной библиотеке. Если у нас есть рабочий xplat nunit runner, это должно быть немного работы.

Помогло бы разбить это на две фазы - своего рода «быстрый и грязный, может быть, уродливый, но, по крайней мере, давайте что-нибудь там выпустим», а затем более полноценную интеграцию позже?

(Например, создание тестов с TFM netstandard1.3 будет иметь большое значение для разблокировки меня для Noda Time.)

@jskeet и @NickCraver вы можете использовать NUnit сегодня с помощью «взлома» NUnitlite, как предлагал

@roji : Это сработало с dnxcore50 (какое-то время я использовал его с Noda Time), но при использовании netstandard1.3 зависимости от NUnit и NUnitLite недействительны.

@jskeet мой тестовый проект нацелен на netcoreapp1.0 и зависит от Nunit + NUnitLite 3.2.1. У меня есть "imports" : [ "dotnet54" ] и работает как шарм ...

@roji : Спасибо за это ...

@roji : У меня все еще возникают проблемы с запуском тестов - не могли бы вы

@jskeet, конечно, вот и все: https://github.com/npgsql/npgsql/tree/dev/test/Npgsql.Tests

@jskeet, импорт тоже должен работать на вас. RC2 меняет несколько вещей, поэтому я перепишу свое сообщение в блоге о том, как тестировать с NUnit 3 с учетом RC2, и опубликую код на GitHub. Я добавлю сюда ссылку, когда это будет сделано, надеюсь, сегодня утром (EST).

@piotrpMSFT, не могли бы вы сэкономить мне время и указать мне вспомогательную библиотеку для создания dotnet-test-nunit ? Я могу искать, но сейчас я ищу несколько вещей, так что помощь будет признательна. Я уверен, что вы тоже заняты, поэтому, если у вас его нет под рукой, не тратьте на это время, я найду.

Я опубликовал обновленную запись в блоге « Тестирование .NET Core RC2 с использованием NUnit 3» для всех, кому это интересно.

@jskeet вам нужен оператор импорта в вашем project.json. Он добавляется по умолчанию в новые шаблоны .NET Core, но его необходимо добавить при обновлении.

Для project.json в консольном средстве запуска;

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

Или в сборке;

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

При обновлении до RC2, наличие на моем пути старых вещей DNX также укусило меня. Что-то проверить.

@rprouse : Спасибо; Теперь я могу строить, и тесты запускаются в Windows. В Linux я вижу «Ссылка на объект не установлена ​​на экземпляр объекта». сообщение на dotnet run , которое мне нужно изучить дальше. Попробую ваш минимальный образец, чтобы увидеть, есть ли у него такая же проблема ...

@jskeet , мы без проблем используем этот подход как в Windows, так и в Linux. См. Примеры здесь и здесь .

@oschwald :

@jskeet Есть несколько причин, это ваша? https://github.com/dotnet/cli/issues/3075

@NickCraver : Нет, я успешно восстановил сеть.

В моем случае у меня есть файл project.json, который работает без зависимости от другого проекта, но не работает с ним. Мне нужно потратить больше времени на то, чтобы придумать полную репродукцию.

@jskeet Gotcha - актуально: https://github.com/dotnet/cli/issues/2469, а канал Slack отлично подходит для project.json отладки в реальном времени, загляните с примерами, и обычно вы можете начать довольно быстро. Для Slack каналы #general и # dotnet-core довольно активны, многие люди проходят через это и помогают следующему человеку.

Хм ... и теперь все работает. Возможно, это была та же проблема, о которой сообщил dotnet restore использовал не тот проект, чтобы исправить ее. В любом случае, сейчас я запускаю тесты Noda Time на Linux, так что ура :) Всем спасибо.

@piotrpMSFT По поводу моего запроса указателей, я нашел все, что мне нужно, и приступил к работе.

Я добавил начальный PR для бегуна dotnet-test-nunit в nunit / dotnet-test-nunit # 1

Он исследует и запускает тесты, но все еще требует некоторой работы, очистки и тестирования. Я сделаю NuGet-канал для артефактов сборки более доступным, если кто-то захочет поиграть с ним.

Если у кого-то есть идеи о том, как я могу отлаживать пакет NuGet, когда он загружается Visual Studio, мне нужна помощь. Пока он не работает в Visual Studio, но это может быть проблемой при установке.

@rprouse : Я был бы рад увидеть, как Noda Time с этим справляется, если это будет полезно. Дайте мне знать, если есть что-то конкретное, что вы хотите, чтобы я проверил. Спасибо за вашу работу!

Он еще не готов к работе в прайм-тайм, но у меня есть тесты NUnit .NET Core, работающие на консоли и в Visual Studio. Есть еще несколько проблем, которые нужно решить, прежде чем я выпущу альфа-версию, но теперь мы намного ближе, так как тяжелая работа сделана, и дело доходит до деталей.

Я опубликую подробности о том, как протестировать сборку CI, после того, как исправлю несколько проблем. Я был бы признателен, если бы люди могли надрать шины и помочь мне найти проблемы.

Вот скриншот.

@rprouse : Есть ли прогресс в сборке CI? Определенно хочет надрать шины; Noda Time использует разумное количество функций NUnit, так что в любом случае это должно быть хорошим началом. Очень жду возможности снова запускать тесты в VS. (Надеюсь, NCrunch и CodeRush для Roslyn тоже начнут поддерживать его, когда он выйдет ...)

@jskeet и другие, которые заинтересованы в том, чтобы обновил свой демонстрационный репозиторий в ветке dotnet-test-nunit чтобы использовать новый dotnet-test-nunit runner.

Сообщайте о проблемах в

Инструкции высокого уровня:

Обновление: dotnet-test-nunit теперь доступен в качестве альфа-версии на NuGet, выберите Include prereleases . Вам больше не нужно обновлять файл nuget.config .

dotnet-test-nunit все еще находится в стадии разработки, поэтому вам нужно будет добавить файл NuGet.Config в свое решение для загрузки пакетов NuGet из каналов NuGet CI NUnit.

Ваш project.json в вашем тестовом проекте должен выглядеть следующим образом;

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": { }
    }
}

Здесь интересуют зависимости от dotnet-test-nunit . Не стесняйтесь использовать последнюю предварительную версию, которая заканчивается на -CI , которая является последней из основной ветки. Обратите внимание, что зависимость NUnitWithDotNetCoreRC2 - это тестируемый проект.

Я добавил "testRunner": "nunit" чтобы указать NUnit 3 в качестве тестового адаптера. Мне также пришлось добавить к импорту как для тестового адаптера, так и для NUnit. Наконец, мне пришлось добавить runtimes . Если кто-нибудь может объяснить, зачем мне это нужно, дайте мне знать.

Теперь вы можете запускать тесты с помощью обозревателя тестов Visual Studio или с помощью команды dotnet test из командной строки.

# 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\

Предупреждение

Как я уже сказал, он все еще находится в стадии разработки. dotnet-test-nunit версия 3.3.0.39-CI, указанная выше, имеет ошибку, из-за которой он выдает ArgumentException при попытке сохранить файл TestResult.xml .

Также обратите внимание, что командная строка dotnet принимает пустые строки и не работает с цветом. Вывод средства запуска тестов NUnit цветной, но вы его не увидите.

Часть "проглатывание пустой строки" - это известная ошибка: https://github.com/dotnet/cli/issues/2234

Спасибо за ссылку @jskeet , похоже, цвет - тоже известная ошибка, dotnet / cli # 1977

ArgumentException исправлено в 3.3.0.49-CI . Я обновлю свои инструкции выше с исправлением. Еще одна нерешенная проблема заключается в том, что в настоящее время я не предоставляю исполнителю номер строки для тестов, поэтому щелчок по тестам в обозревателе тестов Visual Studio не приведет вас к коду.

Правильно ли я говорю, что пока нет поддержки аргументов командной строки, например --where т. Д.? (Я полностью понимаю, что это только начало - просто пытаюсь проверить, смогу ли я это сделать.)

Я пробовал немного другой project.json для вас. Я включил его дословно ниже, но есть важные отличия:

• Я также хочу протестировать среду выполнения рабочего стола, поэтому у меня есть две цели фреймворка.
• Я использую netcoreapp1.0 вместо netstandard1.5
• Я включил зависимость Microsoft.NETCore.App с "type"="platform"
• Смотри, мама, раздела времени выполнения нет. (Возможно, из-за некоторых из вышеперечисленных изменений ...)

{
  "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",
      }
    }
  }
}

Результат:

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

Woot. (Используя net451, я получил тестовое количество 15646, чего я и ожидал.)

Далее: попробуйте то же самое на машине с Linux (где ваш project.json, по-видимому, не будет работать без изменений, поскольку он не упоминает Linux, но мой теоретически должен; сказав это, это машина с Ubuntu 16.04, поэтому ее dotnet CLI несколько сложен вместе).

Хм. Тесты в Linux не завершились после 14 минут использования 100% ЦП. Придется более внимательно посмотреть, что там происходит.

@jskeet

Правильно ли я говорю, что пока нет поддержки аргументов командной строки, например --where и т. Д.?

Плохо протестировано, но я подключил --where и большинство общих параметров командной строки. У меня все еще есть проблема, nunit / dotnet-test-nunit # 4, чтобы проверить, все ли они правильно подключены и работают, и добавить все, что может отсутствовать. Пока я не тестировал много, но использовал несколько, добавив их в конец команды dotnet . Однако мне все еще нужно выяснить, как именно это работает. Например, параметр командной строки --debug работал нормально из решения dotnet-test-nunit , но выдает dotnet-test Error: 0 : Microsoft.DotNet.Cli.Utils.CommandUnknownException: No executable found matching command "dotnet-test-" когда я запускаю его из своего тестового решения. Я также не знаю, как связать командную строку справки с нашей, чтобы показать, что поддерживается.

А пока вы можете взглянуть на https://github.com/nunit/dotnet-test-nunit/blob/master/src/dotnet-test-nunit/CommandLineOptions.cs, чтобы узнать, какие параметры командной строки я считаю поддержал: smile:

Ах, да - похоже, что dotnet test не имеет того же средства, что и dotnet run для разделения аргументов тестовой среды от аргументов до самого dotnet test . Я пытался

dotnet test -- --help

а также

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

Просто используя

dotnet test --where=cat!=Slow

работает отлично. Подам для этого запрос функции - приятно иметь возможность быть полностью недвусмысленным.

Нажатие на тесты и переход к коду теперь фиксируется в 3.3.0.60-CI .

Есть еще две проблемы с высоким приоритетом, и я планирую выпустить альфа-версию, после чего закрою эту проблему и буду отслеживать все в новом репозитории. Две проблемы:

• [x] nunit / dotnet-test-nunit # 22 Добавить сообщения и трассировки стека в неудавшиеся тесты
• [x] nunit / dotnet-test-nunit # 12 TestContext.WriteLine не отображается в сводке теста TestExplorer

К вашему сведению, сегодня я снова запустил тесты Noda Time на своем компьютере с Ubuntu, и они завершились примерно через 15 минут. Похоже, все они работают примерно в 5-6 раз медленнее на моем Linux i5, чем на моем Win10 i7. Не уверен, насколько это связано с процессором и сколько связано с JIT - и это определенно выходит за рамки NUnit :)

@jskeet спасибо за обновление, это хорошие новости. Нужны ли вам моно-привязки для тестов Linux, как указано в nunit / dotnet-test-nunit # 9?

Для всех, кто тестирует, последний хороший пакет NuGet - это 3.3.0.69-CI , попробуйте с ним. Сейчас нет нерешенных проблем, которые, по моему мнению, достаточно серьезны, чтобы заблокировать выпуск. Если на этой неделе ни о чем не сообщается, я, скорее всего, создам альфа-версию позже на этой или в начале следующей недели. Как только я это сделаю, я закрою эту проблему, и дальнейшие обсуждения / проблемы могут быть продолжены в репозитории dotnet-test-nunit .

Испытайте сейчас или навсегда молчите: smile:

@rprouse : Я не пробовал запускать его на Mono - только .NET Core на Linux. Это отлично работало с указанным выше проектом project.json.

Заставит 69-CI взбодриться ...

Одно различие, которое я заметил между этим и средством запуска консольного приложения, заключается в том, что версия «dotnet test», похоже, включает время, потраченное на поиск тестов, в общую продолжительность, тогда как команда «dotnet run», которую я использовал с NUnitLite, не включала . В Noda Time это означает, что если я запускаю с --where=cat==Foo (таких тестов в этой категории нет), то «dotnet test» сообщает о продолжительности 14 секунд, тогда как «dotnet run» сообщает о продолжительности 0,01 с - несмотря на то, что они оба занимают примерно одинаковое реальное время.

Это умышленно? Я, конечно, не возражаю против такого поведения, но, возможно, стоит отметить его где-нибудь, чтобы люди не думали, что оно на самом деле медленнее.

@jskeet , это хорошее наблюдение, это действительно так. Поскольку у нас нет полного движка NUnit для запуска тестов, код более упрощен, но я мог бы запустить часы при первом событии запуска теста, вместо того, чтобы оборачивать тестовый прогон. Я введу вопрос.

Я выпустил альфа-версию dotnet-test-nunit на GitHub по адресу https://www.nuget.org/packages/dotnet-test-nunit/3.4.0-alpha-1 , поэтому вам больше не нужно менять NuGet.config file и используйте выпуски CI.

Теперь, когда у меня есть альфа, я собираюсь закрыть этот выпуск. Пожалуйста, помогите мне протестировать альфа-версию и сообщать о любых проблемах в https://github.com/nunit/dotnet-test-nunit/issues. Финальный релиз планируется выпустить в конце месяца вместе с выпуском NUnit 3.4. Я буду выпускать обновленные альфа- и бета-версии в зависимости от обнаруженных проблем.

Я обновил документацию в файле readme для dotnet-test-nunit . Я буду держать это в курсе.

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

Как я отмечал ранее, вам не нужно указывать время выполнения, если вы используете "type": "platform" для зависимости "Microsoft.NETCore.App" . Учитывая документы xUnit, я думаю, что это предпочтительный подход.

В настоящее время у меня есть запрос на перенос, выполняемый через Travis - если он станет зеленым, Noda Time будет зависеть от этого, так что это должно дать ему некоторое использование. Отлично сделано, сэр ...

Один недостаток, который я заметил только что, означает, что я больше не могу легко тестировать с Mono в Linux. Я считаю, что это не проблема NUnit, это в основном проявление https://github.com/dotnet/cli/issues/3073, но для NUnit. Я все еще надеюсь, что это может быть исправлено в конце концов; на данный момент я с некоторой неохотой собираюсь отключить мои моно-тесты в Трэвисе. ( dotnet test определенно будущее.)