I just started testing xUnit.net, but it doesn't seem to capture any output (Console, Debug, Trace), as I would have expected.
Is that possible? I am using a sample .NET 4.0 class-library with xUnit.net 1.8.
I just started testing xUnit.net, but it doesn't seem to capture any output (Console, Debug, Trace), as I would have expected.
Is that possible? I am using a sample .NET 4.0 class-library with xUnit.net 1.8.
There is a solution as found here: https://xunit.codeplex.com/discussions/211566
Simply add this to your constructor or method where you want debugging output:
In general, it's a bad road to go down to be reliant on logging and tests. The pass/fail should be the outcome of the tests. And they simply shouldn't get to the stage where there's enough stuff going on that looking at a trace will be necessary.
The
xunit.gui.exe
shows Console and Trace output,xunit.console.exe
does not. If it's important, you could hook up a TraceListener which redirects to a file by making appropriate standard .NET config entries (Theres' aFileWriterTraceListener
which you should be able to hook in if you google it).UPDATE: As discussed in his blog post, Damian Hickey has a good example of a possible substitute - wiring logging to the xUnit 2
ITestOutputHelper
as demonstrated in https://github.com/damianh/CapturingLogOutputWithXunit2AndParallelTests/blob/master/src/Lib.Tests/Tests.csUPDATE 2: In some cases, one can add logging and feed it to the
ITestOutputHelper
without involvingLogContext
by using a simple adapter as follows (I only have it in F#, sorry):The difference with this approach vs using the log context is that logging to the global [contextualized] Serilog
Logger
will not get picked up.The situation has changed a little with xUnit.net 2. I know the question is about an earlier version, but as people will land here having performed the upgrade, I thought it was worth pointing this out.
In order to see some kind of output in the test output in version 2 you will need to take a dependency in your test class (via a constructor argument) on an instance of
ITestOutputHelper
, then use theWriteLine
method on this interface. E.g.:You could choose to hook up your logging framework to this interface, perhaps by injecting an
ILog
implementation that forwarded all calls toITestOutpuHelper
.I acknowledge that you won't want to do this by default, but for diagnostic purposes from time to time it can be quite useful. This is especially true where your tests only fail on some cloud based build & test server!
This can help if your
Console.Write
is embedded deep down some class hierarchy that you don't want to refactor: