Skip to content

Commit b916771

Browse files
committed
Add /site/docs content
1 parent 1b23d5d commit b916771

File tree

66 files changed

+7336
-241
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

66 files changed

+7336
-241
lines changed

site/docfx.json

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,9 @@
44
"markdownEngineProperties": {
55
"markdigExtensions": [
66
"attributes",
7-
"customcontainers"
7+
"customcontainers",
8+
"emphasisextras",
9+
"gridtables"
810
]
911
},
1012
"content": [
@@ -18,6 +20,7 @@
1820
"resource": [
1921
{
2022
"files": [
23+
"**/*.js",
2124
"downloads/**",
2225
"images/**",
2326
"schema/**/*.json"

site/docs/capturing-output.md

Lines changed: 185 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,185 @@
1+
---
2+
title: Capturing Output
3+
---
4+
5+
# Capturing Output
6+
7+
In order to assist in debugging failing test (especially when running them on remote machines without access to a debugger), it can often be helpful to add diagnostic output that is separate from passing or failing test results. xUnit.net offers two such methods for adding output, depending on what kind of code you're trying to diagnose.
8+
9+
* xUnit.net v1 always captured output from `Console`, `Debug`, and `Trace`.
10+
11+
* xUnit.net v2 removed this ability and replaced it with an injectable `ITraceOutputHelper` that could be used to capture output from a test.
12+
13+
* xUnit.net v3 reintroduced the ability to capture output, which is disabled by default for backward compatibility with v2.
14+
15+
## Output in unit tests
16+
17+
### xUnit.net v3
18+
19+
xUnit.net v3 reintroduces the ability to capture output that is written to `Console`, `Debug`, and `Trace` through two assembly-level attributes.
20+
21+
> [!NOTE]
22+
> Since this is applied as an assembly-level attribute, the decision to capture output in this way affects all tests in a unit test project.
23+
24+
The `CaptureConsole` attribute will capture output to both standard out and standard error by default. You can choose to capture only one or the other through the use of attribute parameters:
25+
26+
```csharp
27+
// Both standard output and standard error
28+
[assembly: CaptureConsole]
29+
30+
// Only standard output
31+
[assembly: CaptureConsole(CaptureError = false)]
32+
33+
// Only standard error
34+
[assembly: CaptureConsole(CaptureOutput = false)]
35+
```
36+
37+
Similarly, the `CaptureTrace` attribute will capture output to be `Trace` and `Debug` by default. However, due to the way `Trace` and `Debug` interact, you either capture both or none, so there are no parameters:
38+
39+
```csharp
40+
// Captures both Trace and Debug
41+
[assembly: CaptureTrace]
42+
```
43+
44+
Also bear in mind that `Debug` output is only captured when running a Debug build of your unit tests; when running a Release build, all usage of `Debug` is turned off, including output.
45+
46+
xUnit.net v3 tests may also continue to use `ITestOutputHelper` as described below.
47+
48+
### xUnit.net v2
49+
50+
Unit tests in xUnit.net v2 have access to a special interface which replaces previous usage of `Console` and similar mechanisms: `ITestOutputHelper`. In order to take advantage of this, just add a constructor argument for this interface, and stash it so you can use it in the unit test.
51+
52+
```csharp
53+
using Xunit;
54+
using Xunit.Abstractions;
55+
56+
public class MyTestClass
57+
{
58+
private readonly ITestOutputHelper output;
59+
60+
public MyTestClass(ITestOutputHelper output)
61+
{
62+
this.output = output;
63+
}
64+
65+
[Fact]
66+
public void MyTest()
67+
{
68+
var temp = "my class!";
69+
output.WriteLine("This is output from {0}", temp);
70+
}
71+
}
72+
```
73+
74+
As you can see in the example above, the `WriteLine` function on `ITestOutputHelper` supports formatting arguments, just as you were used to with `Console`.
75+
76+
In addition to being able to write to the output system during the unit test, you can also write to it during the constructor (and during your implementation of `IDisposable.Dispose`, if you choose to have one). This test output will be wrapped up into the XML output, and most test runners will surface the output for you as well.
77+
78+
![](/images/capturing-output/vs-runner-output.png){ .border }
79+
80+
To see output from `dotnet test`, pass the command line option `--logger "console;verbosity=detailed"`:
81+
82+
![](/images/capturing-output/dotnet-test-output.png){ .border width=800 }
83+
84+
### Showing live output
85+
86+
Starting with xUnit.net v2 2.8.1 (and runners linked against this version), we have added a new configuration option named [`showLiveOutput`](config-xunit-runner-json#showLiveOutput) to indicate that you would like to be able to see output from `ITestOutputHelper` live as it occurs, rather than just waiting for the test to finish. This is turned off by default as that was the behavior prior to 2.8.1, and showing live output can add significantly to the noise of the output when not needed. We anticipate that users will turn this option on temporarily while debugging through particular issues rather than be something that's left on all the time.
87+
88+
## Output in extensibility classes
89+
90+
Output for unit tests are grouped and displayed with the specific unit test. Output from extensibility classes, on the other hand, is considered diagnostic information. Most runners require you to enable diagnostic output either explicitly with a command line option, or implicitly on an assembly-by-assembly basis by using [configuration files](config-xunit-runner-json).
91+
92+
### xUnit.net v3
93+
94+
Due to the globally available test context, sending diagnostic messages in xUnit.net v3 is quite simple.
95+
96+
Here is an example of sending a diagnostic message in a test case orderer:
97+
98+
```csharp
99+
using System.Collections.Generic;
100+
using System.Linq;
101+
using Xunit;
102+
using Xunit.Sdk;
103+
using Xunit.v3;
104+
105+
public class MyTestCaseOrderer : ITestCaseOrderer
106+
{
107+
public IReadOnlyCollection<TTestCase> OrderTestCases<TTestCase>(IReadOnlyCollection<TTestCase> testCases)
108+
where TTestCase : notnull, ITestCase
109+
{
110+
var result = testCases.ToList(); // ...perform ordering here...
111+
TestContext.Current.SendDiagnosticMessage("Ordered {0} test cases", result.Count);
112+
return result;
113+
}
114+
}
115+
```
116+
117+
xUnit.net v3 extensibility classes may also continue to use `IMessageSink` as described below.
118+
119+
### xUnit.net v2
120+
121+
Each extensibility class has its own individual constructor requirements. In addition, they can take _as their last constructor parameter_ an instance of `IMessageSink` that is designated solely for sending diagnostic messages. Diagnostic messages implement `IDiagnosticMessage` from `xunit.abstractions`. If you're linked against `xunit.execution`, there is a `DiagnosticMessage` class in the `Xunit.Sdk` namespace available for your use.
122+
123+
The extensibility interfaces which currently support this functionality are:
124+
125+
* `IClassFixture<>`
126+
* `ICollectionFixture<>`
127+
* `IDataDiscoverer`
128+
* `ITestCaseOrderer`
129+
* `ITestCollectionOrderer`
130+
* `ITestFrameworkTypeDiscoverer`
131+
* `ITraitDiscoverer`
132+
* `IXunitTestCaseDiscoverer`
133+
* `IXunitTestCollectionFactory`
134+
135+
Here is an example of using it in a test case orderer:
136+
137+
```csharp
138+
using System.Collections.Generic;
139+
using System.Linq;
140+
using Xunit.Abstractions;
141+
using Xunit.Sdk;
142+
143+
public class MyTestCaseOrderer : ITestCaseOrderer
144+
{
145+
private readonly IMessageSink diagnosticMessageSink;
146+
147+
public MyTestCaseOrderer(IMessageSink diagnosticMessageSink)
148+
{
149+
this.diagnosticMessageSink = diagnosticMessageSink;
150+
}
151+
152+
public IEnumerable<TTestCase> OrderTestCases<TTestCase>(IEnumerable<TTestCase> testCases)
153+
where TTestCase : ITestCase
154+
{
155+
var result = testCases.ToList(); // ...perform ordering here...
156+
var message = new DiagnosticMessage("Ordered {0} test cases", result.Count);
157+
diagnosticMessageSink.OnMessage(message);
158+
return result;
159+
}
160+
}
161+
```
162+
163+
### Viewing diagnostic messages in Visual Studio
164+
165+
After [enabling diagnostic messages in your configuration file](config-xunit-runner-json#diagnosticMessages), when run, Visual Studio's output window contains a Tests tab which contains the information from running the tests, including the diagnostic message.
166+
167+
```text
168+
Starting test discovery for requested test run
169+
========== Starting test discovery ==========
170+
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v3.1.1+bf6400fd51 (64-bit .NET 8.0.17)
171+
[xUnit.net 00:00:00.51] Discovering: OutputExample (method display = ClassAndMethod, method display options = None)
172+
[xUnit.net 00:00:00.53] Discovered: OutputExample (found 1 test case)
173+
========== Test discovery finished: 1 Tests found in 1.4 sec ==========
174+
========== Starting test run ==========
175+
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v3.1.1+bf6400fd51 (64-bit .NET 8.0.17)
176+
[xUnit.net 00:00:00.24] Starting: OutputExample (parallel test collections = on, max threads = 24)
177+
[xUnit.net 00:00:00.26] OutputExample: Ordered 1 test cases
178+
[xUnit.net 00:00:00.27] Finished: OutputExample
179+
========== Test run finished: 1 Tests (1 Passed, 0 Failed, 0 Skipped) run in 282 ms ==========
180+
```
181+
182+
> [!NOTE]
183+
> To see this output, open the Output window in Visual Studio (from the main menu: View > Output), and in the "Show output from" drop down, select "Tests".
184+
>
185+
> Also note that the output may look slightly different depending on whether Test Explorer is using VSTest mode or Microsoft Testing Platform mode.

site/docs/comparisons.md

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
---
2+
redirect_url: /
3+
---

0 commit comments

Comments
 (0)