How can one reliably run unittests
deadalnix
deadalnix at gmail.com
Thu Sep 2 17:26:46 UTC 2021
On Tuesday, 31 August 2021 at 16:50:07 UTC, Steven Schveighoffer
wrote:
> So for instance, if you link against library X, and you didn't
> actually build library X with -unittest, then you won't run
> library X's unittests, only the ones in your project.
>
So I was curious at to what was meant by this. Let me try to make
it explicit why the current behavior is nonsense. I ran something
akin to:
```
$ dmd -m64 -Isrc -w -debug -g -main -unittest -i -run
src/somemodule.d
3 modules passed unittests
```
It is clear that this is running random unitests I don't care
about. Module that are brought in via the -i flag are also
compiled with their unittests, which is nonsense.
On the other hand, I made an interesting discovery:
```
$ dmd -m64 -Isrc -w -debug -g -main -unittest -i -run
src/module1.d src/module2.d
```
Will run exclusively the tests for module1.d and ignore module2.d
, which is considered an argument to be passed to the main that
don't exist and is never run.
This is complete nonsense (and means that I simply run a fraction
of my unitests and have no idea how to fix my build to runt hem
all).
You'll note that I didn't find a way to get rdmd to do the right
thing here, so I'm recompiling everything all the time for no
good reason when i want to run the tests, which is also a giant
pain in the ass.
> But my point is, the reason it's done this way is because D
> uses the build system that C uses -- which has a compiler and a
> linker as separate steps.
>
I don't think this is a good reason. There is nothing in the C
style build.link model that prevent us from doing the right thing.
> It's also the reason that cycle detection can't be run until
> program startup.
>
Cool, this can be done at startup from module infos. The problem
is not at this level. The compiler provide set of flags that
provide a sensible behavior. it's all nonsense.
More information about the Digitalmars-d
mailing list