Running tests
Running tests with MSTest, NUnit, or XUnit
You have two approaches to capture tests from a compatible framework: wrapping the command or using the Profiler-Initiated-Collector configuration. With the later approach, you don’t have to modify your startup command.
Minimum System Requirements
MSTest Framework 1.4.0 (a.k.a. MSTest v2) and higher
NUnit 3.10.0 and higher
XUnit 2.3.0 and higher
VSTest.Console.exe 17.2 and higher
Wrapper to the test command
When using MSTest, NUnit, or XUnit, you must wrap the execution with the agent and the test listener will monitor the tests. When test execution is completed, test results will be uploaded automatically.
Here is a sample command with the LabID-only setup:
dotnet ./sl-dotnet-agent/SL.DotNet.dll run --tags mytag --instrumentationMode tests --labId <lab Id> --testStage "Functional Tests" --target "c:\tools\testrunner.exe" --workingDir $(pwd) --targetArgs "MyTest.dll --flag1 true --flag2 false"dotnet ./sl-dotnet-agent/SL.DotNet.dll run --tags mytag --instrumentationMode tests --buildSessionIdFile buildSessionId.txt --testStage "Functional Tests" --target "c:\tools\testrunner.exe" --workingDir $(pwd) --targetArgs "MyTest.dll --flag1 true --flag2 false"PIC Integration
Set environment variables required for profiling and PIC. In the below sample configuration, we consider that agent binaries are unpacked to the $SL_AGENT_ROOT, and the $SL_AGENT_ROOT variable contains an absolute path (relative path could cause issues). Env variables could be set by sourcing script, by setting env variables for docker, using env file for docker/ docker-compose / k8s, etc…
Environment variables should be set in the same session where test runner will be executed.
Avoid setting PIC or Profiling environment variables system-wide or user-wide. It could lead to unpredictable consequences because the profiler and collector will be started for each .NET process in the system. Also, it will conflict with other dotnet agents running in the same scope.
You can now execute your tests in the same session, using regular commands with any needed set of params:
Legacy approach
Starting a test stage
Before running your tests, you must send the SeaLights server a start execution event with the test stage's name.
Running your tests
Now you can run your tests while capturing coverage: Capturing coverage from the app process.
If you’re using a non-supported testing framework, execute your tests with your regular command/script and once the tests are finished, you can upload one or more report files. Supported formats are MSTest (TRX files), xUnit.Net, and NUnit (XML files)
Ending the test stage
Once you run your tests and upload the results, you must send the SeaLights server an end execution event with the test stage's name.
Sample scripts
NUnit Tests integration via PIC
NUnit Tests integration with command wrapper
Last updated
Was this helpful?

