diff --git a/benchmarks/TUnit.Performance.Tests/README.md b/benchmarks/TUnit.Performance.Tests/README.md index 68402475591..dc230548256 100644 --- a/benchmarks/TUnit.Performance.Tests/README.md +++ b/benchmarks/TUnit.Performance.Tests/README.md @@ -37,25 +37,29 @@ dotnet run -c Release ### Native AOT Comparison +Native AOT needs a platform toolchain: the Visual Studio "Desktop development with C++" workload on Windows, the Xcode Command Line Tools on macOS, and `clang` plus the zlib development package on Linux. See the [.NET Native AOT prerequisites](https://learn.microsoft.com/dotnet/core/deploying/native-aot/#prerequisites). + ```bash -# Build for AOT -dotnet publish -c Release -r win-x64 --self-contained -p:PublishAot=true +# Build for AOT (native AOT cannot cross-compile across operating systems, so target the current machine) +dotnet publish -c Release --use-current-runtime --self-contained -p:PublishAot=true -o publish # Run the published executable -./bin/Release/net8.0/win-x64/publish/TUnit.Performance.Tests.exe +./publish/TUnit.Performance.Tests +# On Windows: +./publish/TUnit.Performance.Tests.exe ``` ### Run Specific Benchmarks ```bash # Run only discovery benchmarks -dotnet run -c Release -- --filter *Discovery* +dotnet run -c Release -- --filter '*Discovery*' # Run only execution benchmarks -dotnet run -c Release -- --filter *Execution* +dotnet run -c Release -- --filter '*Execution*' # Run only data source benchmarks -dotnet run -c Release -- --filter *DataSource* +dotnet run -c Release -- --filter '*DataSource*' ``` ## Expected Results diff --git a/docs/docs/comparison/framework-differences.md b/docs/docs/comparison/framework-differences.md index d7091d8a2e8..fcce9daebd4 100644 --- a/docs/docs/comparison/framework-differences.md +++ b/docs/docs/comparison/framework-differences.md @@ -65,7 +65,7 @@ TUnit creates a new instance for every test, with no way to opt out. If you need Consider a multi-tenanted test suite where tests repeat with different tenants injected via `[TestFixtureSource]`. A natural next step is filtering by tenant. In NUnit, you might try using `IApplyToTest` to set a property based on the constructor argument, but it doesn't work — tests are enumerated at startup before the fixture source provides its values. -Because TUnit discovers tests via source generation, constructor arguments are available upfront. You can set properties with `ITestDiscoveryEvent` and filter with `--treenode-filter /*/*/*/*[Tenant=MyTenant]`. +Because TUnit discovers tests via source generation, constructor arguments are available upfront. You can set properties with `ITestDiscoveryEvent` and filter with `--treenode-filter "/*/*/*/*[Tenant=MyTenant]"`. ### Attribute scope diff --git a/docs/docs/examples/filebased-csharp.md b/docs/docs/examples/filebased-csharp.md index 4e0b59d9356..6cf46667dda 100644 --- a/docs/docs/examples/filebased-csharp.md +++ b/docs/docs/examples/filebased-csharp.md @@ -19,7 +19,7 @@ To use TUnit with a file-based C# application, you can follow these steps: #:package TUnit@1.6.0 ``` - - You can also use msbuild props files to include TUnit. By creating a `Directory.build.props` file in the same directory as the csharp file. + - You can also use msbuild props files to include TUnit. By creating a `Directory.Build.props` file in the same directory as the csharp file. ```xml @@ -72,7 +72,7 @@ dotnet project convert Program.cs Single file csharp applications can also be used with msbuild props files. You can create a `*.props` file and the dotnet sdk will automatically include it when running the file-based application. -1. Create a file named `Directory.build.props` with the following content: +1. Create a file named `Directory.Build.props` with the following content: ```xml @@ -112,4 +112,4 @@ Single file csharp applications can also be used with msbuild props files. You c dotnet run file.cs ``` -This will automatically include the `Directory.build.props` file as long as it is in the same directory as the csharp file, and you will be able to run your tests with TUnit. +This will automatically include the `Directory.Build.props` file as long as it is in the same directory as the csharp file, and you will be able to run your tests with TUnit. diff --git a/docs/docs/getting-started/running-your-tests.md b/docs/docs/getting-started/running-your-tests.md index b88a74ba2f6..fbbee910a53 100644 --- a/docs/docs/getting-started/running-your-tests.md +++ b/docs/docs/getting-started/running-your-tests.md @@ -12,8 +12,8 @@ Coverage and TRX reporting are built in. See [Extensions](../extending/built-in- For a simple execution of a project, `dotnet run` is the preferred method, allowing easier passing in of command line flags. -```powershell -cd 'C:/Your/Test/Directory' +```sh +cd path/to/YourTestProject dotnet run -c Release # or with flags dotnet run -c Release --report-trx --coverage @@ -23,8 +23,8 @@ dotnet run -c Release --report-trx --coverage `dotnet test` requires any command line flags to be specified as application arguments, meaning after a `--` - Otherwise you'll get an error about unknown switches. -```powershell -cd 'C:/Your/Test/Directory' +```sh +cd path/to/YourTestProject dotnet test -c Release # or with flags dotnet test -c Release -- --report-trx --coverage @@ -34,8 +34,8 @@ dotnet test -c Release -- --report-trx --coverage If your test project has already been built, you can use `dotnet exec` or just `dotnet` with the `.dll` path -```powershell -cd 'C:/Your/Test/Directory/bin/Release/net8.0' +```sh +cd path/to/YourTestProject/bin/Release/net8.0 dotnet exec YourTestProject.dll # or with flags dotnet exec YourTestProject.dll --report-trx --coverage @@ -43,8 +43,8 @@ dotnet exec YourTestProject.dll --report-trx --coverage or -```powershell -cd 'C:/Your/Test/Directory/bin/Release/net8.0' +```sh +cd path/to/YourTestProject/bin/Release/net8.0 dotnet YourTestProject.dll # or with flags dotnet YourTestProject.dll --report-trx --coverage @@ -57,11 +57,20 @@ On Windows this will be a `.exe` and on Linux/macOS there will be no extension. This can be invoked directly and passed any flags. -```powershell -cd 'C:/Your/Test/Directory/bin/Release/net8.0/win-x64/publish' -./YourTestProject.exe +The publish folder sits under the runtime identifier you published for, such as `win-x64`, `linux-x64` or `osx-arm64`. Replace `linux-x64` below with yours. + +```sh +cd path/to/YourTestProject/bin/Release/net8.0/linux-x64/publish +./YourTestProject # or with flags -./YourTestProject.exe --report-trx --coverage +./YourTestProject --report-trx --coverage +``` + +On Windows, from the `win-x64` publish folder: + +```powershell +cd path/to/YourTestProject/bin/Release/net8.0/win-x64/publish +.\YourTestProject.exe --report-trx --coverage ``` ## IDE Support diff --git a/docs/docs/writing-tests/test-context.md b/docs/docs/writing-tests/test-context.md index 2b6ed64a5ba..e48df372d03 100644 --- a/docs/docs/writing-tests/test-context.md +++ b/docs/docs/writing-tests/test-context.md @@ -100,7 +100,7 @@ See the [Test Parameters](../execution/parameters.md) guide for full details. Custom properties can be added to a test using the `[Property]` attribute. Properties are key-value pairs of strings that serve multiple purposes: -- **Test filtering**: Filter tests at the command line with `dotnet run --treenode-filter /*/*/*/*[PropertyName=PropertyValue]` +- **Test filtering**: Filter tests at the command line with `dotnet run --treenode-filter "/*/*/*/*[PropertyName=PropertyValue]"` - **Runtime logic**: Access properties in setup/cleanup hooks via `TestContext` to conditionally execute logic - **Inheritance**: Apply `[Property]` on a base class and all sub-class tests inherit it