How can one reliably run unittests

[deadalnix]

On Tuesday, 24 August 2021 at 12:39:47 UTC, Atila Neves wrote:
> My ideal scenario wouldn't involve linkers at all - I don't 
> want to spend time waiting for my code to link, especially 
> since, the way I write code means that unit tests never need 
> optimising or native code generated. I'd go as far as to say 
> that if one's unit tests *do* need any of that, they need to 
> rethink their mini-integra... err, unit tests. But I digress.
>

This is not doable in practice ATM. You use an exception from 
another module? you are screwed already, you need to link that 
other module in. This is a UX disaster, though.

> The way I'd like it to work personally would be to CTFE unit 
> tests in a module and have them run whenever I save the file. 
> No linker, no main function, just that.
>

Yes, or if there is a linker behind, I don't want to know about 
it. Slow link time can be a problem, but making it work at all, 
even with slow link time, would be a tremendous step forward.

> Back to the issue at hand. The problem with wanting to pass 
> flags to the rdmd is that unless the project is trivial it'll 
> have dub dependencies, so doing that manually is a no-no. This 
> is the same thing that happens all the time in 
> compile-as-you-type plugins, and why I maintain two separate 
> emacs packages to make that done automatically (one for 
> CMake/C++ and one for dub/D). Which means asking dub. Which 
> means a build system.
>

yes, dub makes this whole problem exponentially worse.

> Which means you just gave me an idea for an awesome reggae rule 
> to generate a library with all of the dependencies of a module, 
> a main function to run the tests, and then voilà. It'd have to 
> do this for each module, and the first time said 
> all-dependencies library is built it'd take time, but after 
> that it'd work.
>

Yes. One problem you'll run into is the `main` issue, where you 
need to use different flags. It is also unfortunate that building 
system have to pay the cost to paper over bad command line UI. 
This is bound to create poor integration in existing toolchains - 
which we see is the case already.

> You'd still have to wait for the linker though, and if for some 
> reason you're not using lld (or worse, you're on Windows), the 
> wait will be looooong.

The alternative is the feature not being usable at all, so I 
don't really care. I can throw hardware at that problem.