Summary
Part of #2162 that was not implemented, because we want to compare the experience between single dll run, and multi dll run (in dotnet test), once we have it available.
By default please also output currently running test + result of passing tests. This is also important when a test does actually hang/crash so you can see what test might have caused it.
Background and Motivation
Show which tests are running so we know when a test is hanging.
Proposed Feature
Show one line for every test in progress and timing.
Make sure the information fits on screen. Decide which tests should be cut off when there are too many to still keep the output useful.
Alternative Designs
Consider the impact of this #3639 where I think it is more appropriate to implement detection of stuck tests closer to the test framework. This also limits the amount of information we will render on screen, and we don't have to consier what will happen when tests run very fast, or how will user figure out if test is stuck.
Summary
Part of #2162 that was not implemented, because we want to compare the experience between single dll run, and multi dll run (in dotnet test), once we have it available.
By default please also output currently running test + result of passing tests. This is also important when a test does actually hang/crash so you can see what test might have caused it.
Background and Motivation
Show which tests are running so we know when a test is hanging.
Proposed Feature
Show one line for every test in progress and timing.
Make sure the information fits on screen. Decide which tests should be cut off when there are too many to still keep the output useful.
Alternative Designs
Consider the impact of this #3639 where I think it is more appropriate to implement detection of stuck tests closer to the test framework. This also limits the amount of information we will render on screen, and we don't have to consier what will happen when tests run very fast, or how will user figure out if test is stuck.