+972 52-548-6969
Command line usability
I hate the new “dotnet test” command. I don’t think that anyone ever thought about looking at the output it generates for real projects.
For example, here is a section form the log output our fast tests:
There is so much crap here, including duplicate information and a whole bunch of mess that it is very hard to find relevant information. For example, there is a failing test here. How long will it take you to find it?
Another important aspect for us is the fact that this will actually run the same process. If you have something that will crash the test process, you’ll never get to see what is going on. Here is what a crash due to stack overflow looks like using “dotnet test”
As a result, we moved to dotnet xunit, which is a much better test runner.
We get color coding, including red for failing tests, so we don’t have to hunt them.
What is more important, it will not hide crucial information from us because it feels like it. If there is a crash, we can actually see what happened.
I know it sounds trivial, but “dotnet test” doesn’t have it.
Comments
I noticed in a recent blog post from Scott Hanselman that his CLI test output was color-coded. It's the last picture in the blog post (direct link). Though he's using "dotnet watch test" rather than just "dotnet test" (to run tests each time a file is changed), but I'm surprised that the output would be so different.
@jadarnel27: It is actually not the output of
dotnet testthat is colored but the output ofdotnet watchitself together with some piped compilation results invoked by the command itself.I assume this is because
dotnet testhas to support the lowest-common-denominator, which I further assume is MSTest. Good job the XUnit team put their own runner in. It's got great support for sending formatted/serialized output to files, too.I suggest you actually read the XUnit docs which cover the DOTNET tool usage with XUNIT. Preferably well BEFORE you write a blog post about it.
See "Write your first tests"
https://xunit.github.io/docs/getting-started-dotnet-core.html
Ideally we would all read all the docs about any product before giving our critique, but that is not realistic. In particular if he had a more deliberate character then I don't know if he would have gone headlong into many of the let-me-try-and-do-it better efforts we see here.
Joshua, My post is actually about the default test runnner, not the xunit one. And you might want to check the date this post went up, and the date the page was updated with this information.
Comment preview