4

I am using xUnit with Visual Studio Test Explorer and when there's an error in Assert.Equal(), I am getting a truncated version of Actual and Expected.

For example,

Xunit.Sdk.EqualException
Assert.Equal() Failure
Expected: List<Result> 
[Result { 
Status = StatusEnumValue1, 
Message = "The request or response type contains a special ty"..., 
Path = "1234" }]
Actual:   WhereListIterator<Result> 
[Result { 
Status = StatusEnumValue1, 
Message = "The request or response type contains a special ty"..., 
Path = "1234" }]

This test fails because the Messages are different, but given that the Messages are truncated, I cannot see the part where they actually are different from the Test Explorer. Even when I copy it out, it's still truncated.

Is this a known shortcoming of xUnit? I can keep debugging the test or use WriteLine to compare the Messages but I am surprised the xUnit framework does not have a way to allow full response to be shown. I also tried the Resharper test explorer, and that does not solve the problem.

KangarooWest
  • 768
  • 2
  • 7
  • 20

3 Answers3

7

It turns out this is an xUnit issue.

ovation22 points own below the exact location of the code that controls this hard limit on number of characters.

I have bypassed this issue by using FluentAssertions library instead. The error from xUnit used with FluentAssertions does not truncate any error message.

KangarooWest
  • 768
  • 2
  • 7
  • 20
3

This appears to be a limitation of Visual Studio. This looks to be resolved with Visual Studio 2017.3.

https://developercommunity.visualstudio.com/content/problem/30703/test-explorer-result-text-truncated.html

ovation22
  • 711
  • 2
  • 7
  • 19
  • I'm already on 2017.3. Even when I resize the window, the message is truncated, always at the same place (in the middle). They might have fixed something similar for MSTest, maybe? I'll try this on a console to see if it's an xUnit problem. – KangarooWest Sep 14 '17 at 17:34
  • 1
    As expected this is the same in console, so it's an xUnit issue. At first, I thought of fixing this by adding a message manually, but alas, they also don't support that out of the box :| https://stackoverflow.com/questions/42203169/how-to-implement-xunit-descriptive-assert-message I can use a workaround by doing Assert.True, which has a message overload, but this is something I really hate to do :( – KangarooWest Sep 14 '17 at 17:41
  • 1
    Looks you're right. I'll see if I can submit a pull request to allow this to be configurable. https://github.com/xunit/xunit/blob/d2935cc4bd9d77df49239f2e6a7174dbe09d1e47/src/xunit.runner.visualstudio/Sinks/VsDiscoverySink.cs – ovation22 Sep 14 '17 at 17:52
  • 1
    Ah thank you! That 447 is a magic number. It looks like fluent assertion https://github.com/fluentassertions/fluentassertions is able to provide this capability, so I'll go with that for now. – KangarooWest Sep 14 '17 at 18:11
-1

There's a very cumbersome way to view the full information using only xUnit and Visual Studio. I'm not familiar with FluentAssertions, but it does sound like an easier way.

Here's the steps to find the untruncated information with just Visual Studio and xUnit:

  1. Right click on the failing test (Ctrl+r, Ctrl+t also works)
  2. A small popup with the Exception will show in Visual Studio
  3. Click "View Details"
  4. This will popup another screen called QuickWatch, that has all of the related information in full untruncated form.
Justin B.
  • 9
  • 4