I typically run my unit tests using dotnet test. The framework I'm using is xunit. As such, I'm not sure how to run dotMemory unit tests with the CLI.
The documentation recommends:
dotMemoryUnit.exe
-targetExecutable="C:\NUnit 2.6.4\bin\nunit-console.exe"
-returnTargetExitCode --"E:\MyProject\bin\Release\MainTests.dll"
What should I put in -targetExecutable? It expects a path, so entering dotnet test doesn't work.
I tried to run tests using latest dotMemory Unit 3.1, it works
dotMemoryUnit.exe "c:\Program Files\dotnet\dotnet.exe" -- test "path\to\the\solution.sln"
For your version it would be
dotMemoryUnit.exe -targetExecutable="c:\Program Files\dotnet\dotnet.exe"
-returnTargetExitCode -- test "E:\MyProject\bin\Release\MainTests.dll"
Related
In Azure Devops for a .Net core application.
I have three steps
dotnet restore
dotnet build
dotnet test
But if I simply run dotnet test that forces a restore and build. Is there any reason to have the first two steps?
You can use them as follows:
dotnet restore
dotnet build --no-restore
dotnet test --no-build
In this way, you will speed up your build as it can use result of the previous command.
This is default behavior so you don't need to always run all commands to run dotent test for instance. It is convinient and still possible to opt-out from thah behavior.
I've been working on our build pipeline for AWS Lambdas and wanted to add the ReadyToRun feature to reduce startup times. I noticed that in order to complete the publishing step, I needed to remove the --no-build flag. This rebuild step seems to run fairly quickly, so it's not a problem, but I'm curious as to why exactly it's needed.
This doesn't seem to be documented anywhere, and without it the runtimeconfig.json isn't compatible with a framework-dependent deployment. So basically --no-build is not compatible with --no-self-contained.
For context, we build in a custom Alipne-based container with the latest .net core 3.1 SDK and some other internal tools. The restore/build step runs first so we can then run all the tests and finally zip up the distributable package which is picked up by the rest of the CI pipeline. Everything after that first step carries the --no-build flag, except now for the dotnet publish step.
The commands boil down to basically this:
dotnet build --configuration Release --runtime linux-x64 # also takes care of the restore step
dotnet test --no-build # with some filters and coverage targets
dotnet publish --configuration Release --runtime linux-x64 --no-self-contained --framework "netcoreapp3.1" /p:ReadyToRun=true /p:GenerateRuntimeConfigurationFiles=true
I am developing an api targeting .NetStandard, and want to test it with different versions of .NetCore.
I would like to run my unit tests against all the currently supported LTS versions of .NetCore, however I cannot figure out how to build the unit tests against the currently installed SDK.
The currently supported versions of .NetCore are 2.1 and 3.1. I can use <TargetFrameworks> to specify that the unit test project can handle both those targets, and when I run on my dev machine everything works fine. However, unlike my dev machine, when Travis runs tests there is only one SDK installed (which is good - I want to know exactly what I'm testing against). The unit test project expects both SDKs to present, however. If I target only 2.1 it fails for 3.1 on Travis, and if I target 3.1 it fails for 2.1.
So, is there a way to test against both LTS versions of .NetCore on Travis-CI with a single unit test project?
Was able to get it working.
In the unit test project use TargetFrameworks instead of TargetFramework to target multiple frameworks. I believe you have to edit the csproj file by hand, I don't think there's a way to set it from the Visual Studio UI. <TargetFrameworks>netcoreapp2.1;netcoreapp3.1</TargetFrameworks>
In .travis.yml, include one framework in the dotnet: section, explicitly install the other framework in the before_install: section, then explicitly invoke the tests with each framework in the script: section:
dotnet: # Include one of the frameworks
- 2.1.804 # EOL for 2.1: 2021.08.21
before_install:
# explicitly install other targeted SDKs side by side
- sudo apt-get install dotnet-sdk-3.1
script:
# explicitly identify the framework when invoking the tests
- dotnet test UnitTests/UnitTests.csproj -f netcoreapp2.1
- dotnet test UnitTests/UnitTests.csproj -f netcoreapp3.1
I have an MSTest project that works fine when being executed with:
dotnet test --logger "trx;LogFileName=Result.trx" --settings tests.runsettings
I am also able to build a self-contained app out of it with:
dotnet publish -c Release -f netcoreapp2.1 --force --self-contained --runtime win-x64
But I have no idea how to run the tests from the produced output.
Calling
dotnet test .\ProjectName.dll --logger "trx;LogFileName=Result.trx" --settings tests.runsettings
fails with the message:
error MSB4025: The project file could not be loaded.
Any hints as how to run this self-contaiend MSTest-Project?
dotnet test now (2022) accepts .dll files to perform test execution.
You are using the wrong tool:
➜ ~ dotnet --help
test Runs unit tests using the test runner specified in the project.
vstest Runs Microsoft Test Execution Command Line Tool.
dotnet test is the tool used to run unit tests defined in a given project. If you are trying to run tests out of a published dll, dotnet vstest is the command you should us. You do that like this:
dotnet publish -o outputdir
dotnet vstest outputdir/your.dll
I am able to "dotnet xunit" when I am in folder where the project is.
How can I do it from command line where I want to pass already compiled dll as a parameter.
dotnet xunit PathToLibrary.dll
I get an error:
No executable found matching command "dotnet-xunit"
I have copied "xunit.execution.desktop.dll" (get from nuget xunit.core.2.3.0) into current folder, but that does not help.
dotnet-xunit is a per-project CLI tool
Consuming these tools requires you to add a <DotNetCliToolReference> element to your project file for each tool you want to use. Inside the <DotNetCliToolReference> element, you reference the package in which the tool resides and specify the version you need. After running dotnet restore, the tool and its dependencies are restored.
So check that your .csproj contains
<ItemGroup>
<DotNetCliToolReference Include="dotnet-xunit" Version="2.3.0" />
</ItemGroup>
then do
dotnet restore
This answer isn't a direct answer to OP, but necessary for users of dotnet xunit
dotnet xunit is removed starting from xunit 2.4 Ref: Release Notes 2.4
Excerpt from the Release Notes:
Unfortunately, this release also removes the dotnet xunit runner, as the stability of the runner was never perfect, and it suffered from many assembly-loading related issues. Users from .NET Core can continue to use VSTest (either inside Visual Studio, or via dotnet test).
So, for xunit framework test use the command
dotnet test