CLI DotNet Testing??
I've been trying to learn about dotnet test and doing some integration tests on my endpoints. I don't have a specific goal in mind, just mashing away at code like a monkey and see what works. I was trying to get a nice, human readable output in the cli but I've been beating my head on the wall for a day now between youtube videos, etc. It's dawning on me that testing packages like xunit or mstest are meant to be used in conjuction with the Testing UI (i'm using VS Code for example) and not optimized for CLI readability. am I correct? should I abandon trying to make alterations for command line readability and just use the UI?
As I type this I realize it may sound like a stupid question but please humor me. I tend to work everything in command line just out of habit and I'm curious if that's an off-the-shelf wheel I can install or if that would basically be way more customization than it is worth.
9 Replies
Did you try just running
dotnet test?literally the first thing I did
Right. So the issue is that the output of that is not pretty enough, so you'd like to capture it and display it your own way?
I mean it's unreadable. the failures from different tests are repeated, interwoven, multiple stack traces for each failure. it's not human readable in the least.
Depends on the testing framework and runner, I'd imagine? I'm getting pretty decent output from TUnit, albeit it's localized for some godforsaken reason
You'd have to look into getting machine-readable output from the specific framework and/or runner you're using, and parsing that
Mine didn't look anything like that. this is four tests I just spammed until the api returned 429 so I could get errors.
As I said, different frameworks will have different output
Ultimately, if I were a betting man, I'd say 90% of people out there will just use the IDE integration and both run and view the tests that way
The CLI output being more for CI/CD
I think I'm going to join the 90% for now 😆