June 20

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.

June 20

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.