Console.WriteLine calls during dotnet test are not emitted to the console on Windows

Jon Sequeira (@jonsequitur)

From Jon Sequeira (@jonsequitur) on December 15, 2016 19:10

Steps to reproduce

Add a Console.WriteLine call in a test, .e.g GivenThatIWantToMigrateTestApps.ItMigratesRootProjectAndReferences
On Windows, dotnet test --test-case-filter "FullyQualifiedName=Microsoft.DotNet.Migration.Tests.GivenThatIWantToMigrateTestApps.ItMigratesRootProjectAndR eferences"

Expected behavior

The string passed to Console.WriteLine appears in console output.

Actual behavior

C:\dev\github\cli\test\dotnet-migrate.Tests [rel/1.0.0 ↓ +0 ~2 -0 !]> dotnet test --test-case-filter "FullyQualifiedName=Microsoft.DotNet.Migration.Tests.GivenThatIWantToMigrateTestApps.ItMigratesRootProjectAndR
eferences"
Build started, please wait...
Build completed.

Test run for C:\dev\github\cli\test\dotnet-migrate.Tests\bin\Debug\netcoreapp1.0\dotnet-migrate.Tests.dll(.NETCoreApp,Version=v1.0)
Microsoft (R) Test Execution Command Line Tool Version 15.0.0.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...
Passed   Microsoft.DotNet.Migration.Tests.GivenThatIWantToMigrateTestApps.ItMigratesRootProjectAndReferences(projectName: "ProjectB", expectedProjects: "ProjectB,ProjectC,ProjectD,ProjectE")
Passed   Microsoft.DotNet.Migration.Tests.GivenThatIWantToMigrateTestApps.ItMigratesRootProjectAndReferences(projectName: "ProjectA", expectedProjects: "ProjectA,ProjectB,ProjectC,ProjectD,ProjectE")
Passed   Microsoft.DotNet.Migration.Tests.GivenThatIWantToMigrateTestApps.ItMigratesRootProjectAndReferences(projectName: "ProjectC", expectedProjects: "ProjectC,ProjectD,ProjectE")
Passed   Microsoft.DotNet.Migration.Tests.GivenThatIWantToMigrateTestApps.ItMigratesRootProjectAndReferences(projectName: "ProjectE", expectedProjects: "ProjectE")
Passed   Microsoft.DotNet.Migration.Tests.GivenThatIWantToMigrateTestApps.ItMigratesRootProjectAndReferences(projectName: "ProjectD", expectedProjects: "ProjectD")

Total tests: 5. Passed: 5. Failed: 0. Skipped: 0.
Test Run Successful.
Test execution time: 32.2825 Seconds

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview5-004253)

Product Information:
Version: 1.0.0-preview5-004253
Commit SHA-1 hash: 0caae96daf

Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64
Base Path: C:\dev\github\cli\artifacts\win10-x64\stage2\sdk\1.0.0-preview5-004253

Copied from original issue: dotnet/cli#5033

Krzysztof Wicher (@krwq)

From Krzysztof Wicher (@krwq) on January 5, 2017 23:46

Jon Sequeira (@jonsequitur) You should probably be using Xunit's ITestOutputHelper. making Console.WriteLine forward to that might be slightly harder

Jon Sequeira (@jonsequitur)

From Jon Sequeira (@jonsequitur) on January 6, 2017 4:35

The issue that I was seeing was that this works on OS X but not on Windows.

codito

I am seeing that too on windows. None of the Console.WriteLine from my tests gets printed out. We should not ask users to use special APIs to print to the console.

codito Faizan Ahmad (@Faizan2304) Can you guys take a look?

I think we should move this bug to the vstest repo.

Faizan Ahmad (@Faizan2304)

I think this should be handled by adapters at some level. MSTest for instance captures and sends the console outputs to the runner, I think we are including them in trx logger, but not in the console. We can start showing them in console. cc: Faizan Ahmad (@Faizan2304)

There were a few requests to capture console output in xunit:
https://xunit.github.io/docs/capturing-output.html suggests to use IOutputHelper
xunit/xunit#1141

Fixed!!

Faizan Ahmad (@Faizan2304)

Faizan Ahmad (@Faizan2304) Is it fixed in Visual Studio Community 2017 Version 15.2 (26430.15) Release? I still cannot get the output in the output window or the test explorer. I'm using xunit.

I also still do not see test output and would love to, please.

From dotnet test output:

Test ...Tests\bin\Debug\netcoreapp2.0\~.dll(.NETCoreApp,Version=v2.0)
Microsoft (R) Test Execution Command Line Tool Version 15.3.0-preview-20170703-02

and in csproj:

    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.3.0-preview-20170628-02" />
    <PackageReference Include="xunit" Version="2.2.0" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.2.0" />

(I am using preview version of VS and latest dotnet core from github)

Zou Wei (@zwcloud)

Sorry for the late reply. I missed this thread.
Zou Wei (@zwcloud): We have fixed it in vstest.console of version v15.3.0-preview-20170517-02 and it is part of Visual studio 2017 Update3 preview3. Please see below answer to see test output with xunit.

Chris Rogus (@rogusdev) : How are you writing output from test method? Is it Console.WriteLine ?
If yes then it seems xunit doesn't support that.
There were a few requests to capture console output in xunit:
https://xunit.github.io/docs/capturing-output.html suggests to use IOutputHelper
xunit/xunit#1141

Faizan Ahmad (@Faizan2304)

Faizan Ahmad (@Faizan2304)

Is it Console.WriteLine ?
If yes then it seems xunit doesn't support that.

Yes. But Brad Wilson (@bradwilson) said in xunit#1141

There is no way to see that output with dotnet test because of limitations in the VSTest runner.

We do not capture stdout (users are free to use that if they so choose). Our output capture system pushes that information into the test result rather than to stdout. The TRX report may or may not generate reports which include "output" results (I don't personally know, since I have no knowledge of this format), but today there's no simple way today to get this output from dotnet test directly on the console.

Visual Studio's UI, on the other hand, offers ready access to "output", which is where this information is captured.

So.. could you fix or change the behaviour of VSTest runner to remove the limitaion?

Zou Wei (@zwcloud)

Zou Wei (@zwcloud):
We display what adapter sends in TestResult.Message Code here And here

Its the responsibility of adapter to fill console.WriteLine message in TestResult.Message.

But as you can see, Brad Wilson (@bradwilson) said in xunit#1141 that they are not capturing console output to test result

Users will use ITestOutputHelper to write output. That's what ends up in ITestResultMessage.Output. We do not capture any device like console, debug, or tracing.

In this case you have to follow this article. xunit is suggesting to use IOutputHelper to log your message.

Why the issue is closed if there is still no console output in tests?

It's kinda strange to have console test runner which doesn't show console output.

Bumping this in case anyone else comes along hoping to find an answer.

dotnet test -v n

I learned that running the above will show the "Standard Output Messages:" that you would expect from Console.Write*. It does flood the terminal with information at build but at least is a solution for the time. "-v" is a Verbosity argument. "n" represents "normal". Refer here for more information.

I use this with a .NET Core Unit / Integration test projects running NUnit.

Brad Wilson (@bradwilson)

Brad Wilson (@bradwilson) What results? There have been no results in 6 years.

Jeff (@peabnuts123)

Jeff (@peabnuts123) I was on a long leave and I am just back. I will read all this thread and try to give some information/ask for plan about this.

Jeff (@peabnuts123)

Thank you for making this point Jeff (@peabnuts123), it's unbelievable that such a major framework should be broken in such fundamental way for so long, and on Windows of all platforms. I was mortified when I found out our Mac developers had been having a completely different experience with this all this time.

Wow, on a leave for 6 years... And the issue didn't get assigned to anyone else...

It would be great if this discrepancy could be resolved. I'm surprised it's been outstanding for so long. This is making it harder for me to debug issues during testing for libraries that I do not govern, and as such cannot modify their methods of outputting to the console; I can see their logs in Linux, but not Windows.

I am on Windows, and when I first setup xunit a few days ago (using the ITestOutputHelper, I did not need to pass extra args to dotnet test... not sure what changed, but now nothing is output unless I add the --logger "console;verbosity=detailed" arg.

Kind of weird how it changed. Unfortunately I cannot pinpoint what could have possibly affected it.

Is there a way to make --logger "console;verbosity=detailed" the default?

Hello. Is there any update on this egregious seven year old bug affecting users running on Windows, a platform I understand the project owner has some interest in?

Console log debugging is a real pain now.

It's not always possible to inject IOutputHelper into a class.

pluma9 (@pluma9)

pluma9 (@pluma9) this should work without needing to pass in ioutputhelper https://github.com/SimonCropp/XunitContext/

it's amazing that after an hour of pulling my hair out as to why this wasn't working, I'm back to using linux on windows to debug a windows application. Microsoft will be Microsoft.

Navigation Menu

Repository navigation

Console.WriteLine calls during dotnet test are not emitted to the console on Windows #799

Steps to reproduce

Expected behavior

Actual behavior

Environment data

56 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Console.WriteLine calls during dotnet test are not emitted to the console on Windows #799

Description

Steps to reproduce

Expected behavior

Actual behavior

Environment data

Activity

livarcocc commented on May 10, 2017

livarcocc commented on May 10, 2017

livarcocc commented on May 10, 2017

codito commented on May 11, 2017

Faizan2304 commented on May 16, 2017

zwcloud commented on Jul 29, 2017

rogusdev commented on Aug 4, 2017

Faizan2304 commented on Aug 8, 2017

zwcloud commented on Aug 8, 2017

Faizan2304 commented on Aug 8, 2017

evil-shrike commented on Sep 1, 2017

ValorMorgan commented on Mar 14, 2018

56 remaining items

emmenlau commented on Mar 17, 2023

Evangelink commented on Apr 12, 2023

kodeo commented on May 3, 2023

chhh commented on May 4, 2023

jacobjmarks commented on Jul 25, 2023

ReenigneArcher commented on Sep 18, 2023

kodeo commented on Jan 24, 2024

pluma9 commented on Feb 4, 2024

SimonCropp commented on Feb 4, 2024

HassanJbara commented on Apr 21, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions