Over a million developers have joined DZone.

Command Line Usability With dotnet Test

DZone's Guide to

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.

Free Resource

RavenDB 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.

Get comfortable using NoSQL in a free, self-directed learning course provided by RavenDB. Learn to create fully-functional real-world programs on NoSQL Databases. Register today.

performance ,usability ,command line ,dotnet

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}