• Brother Bill (15/15) Nov 30 I notice that dub test will stop at the first unit test failure.
• monkyyy (5/20) Nov 30 intended, theres ways to access the unit test list and at least
• Steven Schveighoffer (22/37) Nov 30 By default, all unittests are called from a generated function

Brother Bill <brotherbill mail.com> writes:

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?

monkyyy <crazymonkyyy gmail.com> writes:

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?

intended, theres ways to access the unit test list and at least 
one extension to it

It doesnt exist but id prefer something that does 10 tests in  
and stops after 5 failed tests or something

Steven Schveighoffer <schveiguy gmail.com> writes:

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