• Sahan (19/19) Jun 19 Hello,
• Sahan (9/11) Jun 19 Looked into this some more, it appears they are being run after

Sahan <sahan.h.fernando.alt gmail.com> writes:

Hello,

I am fairly new to the d programming language, apologies if there 
is an existing discussion for this topic that I've missed. I've 
noticed that `dub test` takes a noticable while longer to run 
than `dub run` for my projects despite my best efforts to keep my 
tests lean, and when digging in to why, I started seeing signs 
that the unit tests for dependencies are being compiled in to my 
test binary (observed by running `objdump -t prog-test-library | 
grep -i unittest`, a lot of these functions are clearly from 
unittest blocks in dependencies that I am importing, and not from 
my code).

Is this an intended behaviour? I am confused as to why this is 
the case, it doesn't appear like they get run at any point. An 
interesting thing I've noticed is it appears that most of my 
dependencies don't have their unittest blocks compiled in, it's 
only modules from a few of them (a lot of them are from mir). The 
number of test functions from dependencies outnumber my own test 
functions 2-1, so I am hoping it is possible to trim my test 
times by not compiling them somehow if it's at all possible.

Sahan <sahan.h.fernando.alt gmail.com> writes:

On Thursday, 20 June 2024 at 03:07:09 UTC, Sahan wrote:
 Is this an intended behaviour? I am confused as to why this is 
 the case, it doesn't appear like they get run at any point.

Looked into this some more, it appears they are being run after 
all, though I am still confused as to why it is compiling them.

Looking at the source of the dependency, I can't determine what's 
causing those specific modules to have their tests compiled. The 
simplest local repro for this issue is creating a new project 
using dub init and adding mir as a dependency, beyond that point 
`dub test` always reports 8 modules that have had their unittests 
pass successfully.