Search code examples
c#unit-testing.net-corefluent-assertions

Is there a way to reduce the stack trace (noise) when using FluentAssertions?


I'm using the FluentAssertions library in a .dotnet core project. I really appreciate the easy with which I can read and understand tests with this 'grammar'.

I am developing this project in VSCode; it's actually running out of a Docker container.

For continuous testing I am running from the console window:

dotnet watch --project ./test-project test

When a test fails, I get the complete stack trace in the output. This can amount to ten or more lines, most of which are directly related to the actual FluentAssertions library exception and not the code under test. This is a lot of noise that I do not need or want. Primarily, it means I need to remove my attention from the code and deal with scrolling and looking for the details of the failed test.

Is there a way to silence the stacktrace?

Alternately, is there other tooling I can use with VSCode to visualize the errors and not have to use the console output.

For completeless I should also point out that I am using xUnit and the dotnet-test-explorer extension.


Solution

  • I have a sort of answer - xUnit and the dotnet-test-explorer don't play well out-of-the-box together.

    I had to:

    • ensure that my assembly name matched the root namespace
    • enable the extensions watching
      • "dotnet-test-explorer.autoWatch": true
    • set the path to the test project
      • "dotnet-test-explorer.testProjectPath": "src/Tests/*.csproj"
    • set the commandline args to get the gutters extension working again
      • "dotnet-test-explorer.testArguments": "/p:CollectCoverage=true /p:CoverletOutputFormat=lcov /p:CoverletOutput=./lcov.info "

    From time to time the lcov.info file gets wiped out, not sure of the direct cause, simple enough fix though - delete the 0byte file and refresh the test list.

    Gonna try running the dotnet watch ... with the generate coverage args from the console while the explorer does it's own thing.

    While this doesn't answer the initial question, it does give me a workable solution that I can live with.