unit test - only shows first fail

Steven Schveighoffer schveiguy at gmail.com
Sun Nov 30 19:37:20 UTC 2025


On Sunday, 30 November 2025 at 11:42:12 UTC, Brother Bill wrote:
> I notice that dub test will stop at the first unit test failure.
> Is this a feature or a bug?
>
> Most Unit Test engines will run all the unit tests then give a 
> report such as:
> 10 files checked.  4 failed, 6 passed, with a list of files for 
> each.
>
> In the old days, compilers would generate 300 errors, most of 
> which were useless.
> Then Lightspeed C came out and stopped at the first error.
> You were supposed to fix that one, then recompile to find any 
> others.
> This made Lightspeed C much faster to compile as it didn't 
> waste time after finding the first error.
>
> Should D developers fix one unit test at a time in a similar 
> manner?

By default, all unittests are called from a generated function 
per module. Each module runs until the first failure of that 
module, then it moves onto another module.

Unittest frameworks like silly or unit-threaded run all unittests 
individually, and they will do it like you say.

But bear in mind that unittests may not be built to properly 
clean up after themselves if a failure occurs.

In general, you should maintain a set of unittests such that they 
all are passing. Then you add/modify one unittest at a time. So 
it doesn't matter what order you fix them in.

However, this doesn't always match real world development. 
Sometimes you change how something works, and it breaks a whole 
slew of unittests.

Where I have found pain is when a unittest maybe takes a long 
time to run (this was happening on my newgc code). This means 
that if the long-running unittest passes, you have to wait for it 
to finish to get to a failing ones.

IMO, the most important fix for unittests in the language would 
be to enable testing individual unittest functions from the 
command line.

-Steve


More information about the Digitalmars-d-learn mailing list