dotnet test equivalent of minimumExpectedTests

Question

I am currently look to move a step in a pipeline from using VSTest@2 to use dotnet test instead. I have read that you can configure dotnet test by using a .runsettings file. However there seems to be settings available in VSTest@2 that I cannot find corresponding setting for dotnet test.

One of these is minimumExpectedTests which will fail the step if it drops below a given number of tests. Can this be done with dotnet test?

# Existing step
- task: VSTest@2
  inputs:
    testSelector: 'testAssemblies'
    testAssemblyVer2: bin\Release\**\Foo.*.Tests.dll
    searchFolder: '$(System.DefaultWorkingDirectory)'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'
    # Should fail if 500 tests are not run
    failOnMinTestsNotRun: true
    minimumExpectedTests: '500'

# New step
- task: DotNetCoreCLI@2
  inputs:
    command: 'test'
    projects: **\bin\Release\**\Foo.*.Tests.dll
    publishTestResults: false
    arguments: '--v normal -s test.runsettings'
    testRunTitle: 'Run Tests'

Answer 1

As far as I know, some parameters of vstest are currently only supported in vstest@2. (e.g. minimumExpectedTests, uiTests).

For Dotnet test, arguments supports the following parameters:

dotnet test [<PROJECT> | <SOLUTION> | <DIRECTORY> | <DLL>]
    [-a|--test-adapter-path <PATH_TO_ADAPTER>] [--blame]
    [-c|--configuration <CONFIGURATION>]
    [--collect <DATA_COLLECTOR_FRIENDLY_NAME>]
    [-d|--diag <PATH_TO_DIAGNOSTICS_FILE>] [-f|--framework <FRAMEWORK>]
    [--filter <EXPRESSION>] [--interactive]
    [-l|--logger <LOGGER_URI/FRIENDLY_NAME>] [--no-build]
    [--nologo] [--no-restore] [-o|--output <OUTPUT_DIRECTORY>]
    [-r|--results-directory <PATH>] [--runtime <RUNTIME_IDENTIFIER>]
    [-s|--settings <SETTINGS_FILE>] [-t|--list-tests]
    [-v|--verbosity <LEVEL>] [[--] <RunSettings arguments>]

dotnet test -h|--help

You can add these parameters to increase the function of dotnet test.

But some of the Vstest@2 parameters are not support in this task. And it seems that there is no workaround to meet your needs.

This feature indeed could make sense. You could submit a suggestion ticket about this feature in our UserVoice website.