Command Line Usability With dotnet Test
Command Line Usability With dotnet Test
I hate the new dotnet test command. It doesn't have good usability. It includes lots of duplicate info and makes it hard to find relevant info like failing tests.
Join the DZone community and get the full member experience.
Join For FreeRavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.
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 from 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.
The picture below shows what a crash due to stack overflow looks like when using “dotnet test.”
As a result of this, 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 is that 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 even have it.
Do you pay to use your database? What if your database paid you? Learn more with RavenDB.
Like This Article? Read More From DZone
Published at DZone with permission of Oren Eini, CEO RavenDB , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}