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
