.NET Core 1.0 — как запустить все тесты в решении с помощью командной строки xUnit

Начало работы с xUnit.net (.NET Core/ASP. NET Core) описывает, как запускать тесты с помощью dotnet test командной строки.

В нем указано, что для этого требуется определенный project.json, куда мы добавляем зависимости xunit и средство запуска тестов:

  "testRunner": "xunit",
    "dependencies": {
        "xunit": "2.1.0",
        "dotnet-test-xunit": "1.0.0-rc2-build10015"
    }

Если я попытаюсь вызвать его из родительского каталога:

C:\git\Project\test [master ≡]> dotnet test
dotnet-test Error: 0 : System.InvalidOperationException: C:\git\Project\test\project.json does not exist.
   at Microsoft.DotNet.Tools.Test.TestCommand.GetProjectPath(String projectPath)
   at Microsoft.DotNet.Tools.Test.TestCommand.DoRun(String[] args)
C:\git\Project\test [master ≡]>

Вопрос. Можно ли запустить все тесты (несколько project.json) с одним dotnet test?


.net-core asp.net-core xunit dotnet-cli .net-core-rc2
person Bruno Garcia    schedule 19.05.2016    source источник
comment
Я не думаю, что есть. Для этого драйвер dotnet должен быть умнее. Это один из аргументов, почему они вернутся к msbuild для системы сборки .NET Core.   -  person Thomas    schedule 19.05.2016
comment
Для Core 2.1 вы можете использовать dotnet vstest. См. stackoverflow.com/questions/47632734/   -  person diegosasw    schedule 11.09.2018

Ответы (6)


arrow_upward
9
arrow_downward

На случай, если кто-то ищет ответ Windows, вот oneliner в PowerShell, который выполняет эту работу:

dir test | % { dotnet test $_.FullName }

person Andrzej Lichnerowicz    schedule 05.10.2016
comment
Этот справился с задачей на VSTS, а локальные скрипты старой школы всегда работают! - person Raffaeu; 22.01.2017

arrow_upward
6
arrow_downward

Поскольку прошел почти месяц, а ответа нет, я хотя бы поделюсь тем, что я делал. (это не будет актуально после запуска Visual Studio "15" RTM, поскольку project.json мертв)

Просто используя цикл for для всех project.json:

Локально из каталога test я просто запускаю:

for /f %a in ('dir /b /s project.json ^| find /v "TestUtilities"') do dotnet test %a

Запускаем его во всех файлах project.json, кроме тех, где в пути указано: TestUtilities.

Имейте в виду, что в TeamCity вам нужно экранировать % (а в сценариях вам нужно двойное: %%), поэтому это выглядит так:

for /f %%%a in ('dir /b /s project.json ^| find /v "TestUtilities"') do dotnet test %%%a

Обратите внимание %%%. Поскольку % в TeamCity используется для переменных, третий % избегает его.

person Bruno Garcia    schedule 03.06.2016
comment
Делая что-то очень похожее на @Bruno, но добавляя дополнительную помощь. Запустив это как сценарий powershell в моем задании CI после dotnet publish из корня моего проекта, несколько проектов модульного тестирования находятся в /test: $dir = dir -dir test foreach($d in $dir){ dotnet test test\$d --no-build -xml ../TEST-$d.xml } - person steamrolla; 02.09.2016

arrow_upward
3
arrow_downward

У ребят из Serilog есть пример создания нескольких тестовых проектов в конвейере CI. Посмотрите этот скрипт powershell https://github.com/serilog/serilog/blob/dev/Build.ps1#L44

person Artur Karbone    schedule 12.12.2016

arrow_upward
2
arrow_downward

Спасибо Andrzej Lichnerowicz за начальный указатель. Я пытался интегрироваться с AppVeyor, и хотя это исправление выполняло все тестовые сборки, сборка больше не прерывалась, если какие-либо тесты не срабатывали.

Переходя на следующий уровень, я создал макрос powershell, импортированный в сборку appveyor...

version: 1.0.{build}
install:
  - ps: Import-Module .\Appveyor.psm1
before_build:
- ps: dotnet restore
build:
  verbosity: minimal
test_script: 
- ps: Invoke-AppVeyorTest

...и затем выполнил следующий макрос:

function Invoke-AppVeyorTest 
{
    [CmdletBinding()]
    param()

    $result = "true"
    Get-ChildItem NetCoreXunit* -Recurse -Directory | % { 
        $test_path = $_.FullName
        $output = & dotnet test $test_path
        if ($output -Match ", Failed: 0, ")
        {
            Write-Output "All tests passed in $test_path"
        }
        else
        {
            Write-Output "Located failed tests in $test_path"
            $result = "false"
        }    
    }
    if ($result -eq "false")
    {
        $host.ui.WriteErrorLine("Failed tests detected.")
        exit 1
    }
}

Appveyor сопоставляет все результаты тестов, и сборка снова завершается ошибкой, если какие-либо тесты не пройдены.

person 9swampy    schedule 30.10.2016

arrow_upward
1
arrow_downward

Для кроссплатформенного решения вы можете использовать Node и NPM с пакетом foreach-cli. Если у вас нет package.json в корневой папке, сделайте npm init, затем:

npm install foreach-cli -D

In package.json:

"scripts : {
  ...
  "test": "foreach -g 'test/**/project.json' -x 'cd #{dir} && dotnet test'"
}

Чтобы запустить тесты:

npm test
person Geir Sagberg    schedule 19.07.2016

arrow_upward
1
arrow_downward

Не похоже, что это вообще возможно через командную строку, учитывая последние отзывы команды CLI о недавнем ошибка github, связанная с алгоритмом поиска проекта:

...хотя команда решила двигаться в другом направлении. В частности, мы решили, что для всех команд требуется путь к корневому артефакту, из которого определяется замыкание.

Однако, если вы используете сборки TFS, существует опция на этапе сборки dotnet (в настоящее время «Предварительная версия»), называемая «Проект(ы)», которая принимает подстановочные знаки, поэтому вы можете использовать следующие настройки для запуска всех тестов во всех точка сети;

Command: 'test' Projects: '**/project.json'

Однако будьте осторожны, **/project.json попытается выполнить тесты во всех проектах, даже если они не имеют определенного testrunner, что может привести к сбою сборки.

person Squiggle    schedule 03.11.2016
comment
Это именно то, чего я пытаюсь добиться, тем не менее, результаты теста выглядят странно. - person Raffaeu; 21.01.2017
comment
результаты теста «выглядят странно»? Вы можете остановиться на этом? У меня этот подход работает в VSTS, и до сих пор у меня не было проблем с ним. - person Squiggle; 23.01.2017