Xunit.Runner.Http
2.0.0-merge.18
dotnet add package Xunit.Runner.Http --version 2.0.0-merge.18
NuGet\Install-Package Xunit.Runner.Http -Version 2.0.0-merge.18
<PackageReference Include="Xunit.Runner.Http" Version="2.0.0-merge.18" />
paket add Xunit.Runner.Http --version 2.0.0-merge.18
#r "nuget: Xunit.Runner.Http, 2.0.0-merge.18"
// Install Xunit.Runner.Http as a Cake Addin #addin nuget:?package=Xunit.Runner.Http&version=2.0.0-merge.18&prerelease // Install Xunit.Runner.Http as a Cake Tool #tool nuget:?package=Xunit.Runner.Http&version=2.0.0-merge.18&prerelease
Xunit.Runner.Http
Enables you to run your tests via http requests instead of the Test Explorer.
Why?
When writing acceptance/integration tests it's useful to be able to debug the system under test and the tests themselves at the same time. I've found that the current tooling doesn't provide a great developer experience for doing so.
Alternatives
These are the alternatives I've used in the past and found to be lacking.
Microsoft.AspNetCore.TestHost
I found that this option has a few downfalls for the way I like to work.
- Requires application configuration to be in the test project. This usually leads to a lot of duplication of configuration or clunky workarounds.
- Acceptance tests written with TestHost can't be run against a live environment like in a CI/CD pipeline against an ephemeral environment.
Two Visausl Studio Instances
By opening the same solution in two instances of Visual Studio you can run the system under test in debug mod in one instance and use the Test Explorer to debug your tests in another. This is clunky at best.
Overview
This package will automatically discover your tests and expose them using Minimal API Get endpoints. You can then invoke your tests by doing a get request to the fully qualified name of your test method. For example if you have the following test:
namesapce MyNamespace;
public class MyTestClass
{
[Fact]
public void MyTestMethod()
{
}
}
You can invoke it by doing a GET request to /MyNamespace.MyTestClass.MyTestMethod
. The response will contain either "Passed" or the xUnit failure message you're used to seeing in Test Explorer.
List of Tests in SwaggerUI
Passing Test
Failing Test
Usage
In order to use this library you'll need to turn your test project into Microsoft.NET.Sdk.Web
project and add a Program.cs
file that creates a web app. Then you'll need to:
Register the test runner with dependency injection:
services.AddXunitHttpTestRunner(typoef(MyTestAssembly).Assembly);
Tell the application to use the test runner:
app.UseXunitHttpTestRunner();
That's it!
See the Samples for a runnable example.
Product | Versions Compatible and additional computed target framework versions. |
---|---|
.NET | net6.0 is compatible. net6.0-android was computed. net6.0-ios was computed. net6.0-maccatalyst was computed. net6.0-macos was computed. net6.0-tvos was computed. net6.0-windows was computed. net7.0 was computed. net7.0-android was computed. net7.0-ios was computed. net7.0-maccatalyst was computed. net7.0-macos was computed. net7.0-tvos was computed. net7.0-windows was computed. net8.0 was computed. net8.0-android was computed. net8.0-browser was computed. net8.0-ios was computed. net8.0-maccatalyst was computed. net8.0-macos was computed. net8.0-tvos was computed. net8.0-windows was computed. net9.0 was computed. net9.0-android was computed. net9.0-browser was computed. net9.0-ios was computed. net9.0-maccatalyst was computed. net9.0-macos was computed. net9.0-tvos was computed. net9.0-windows was computed. |
-
net6.0
- xunit (>= 2.8.0)
- xunit.runner.utility (>= 2.8.0)
NuGet packages
This package is not used by any NuGet packages.
GitHub repositories
This package is not used by any popular GitHub repositories.
Version | Downloads | Last updated |
---|---|---|
2.0.0-merge.18 | 1,869 | 5/6/2024 |
2.0.0-latest-xunit.17 | 70 | 5/6/2024 |
0.1.0 | 584 | 12/11/2023 |