How can one reliably run unittests

jfondren julian.fondren at gmail.com
Fri Sep 3 00:34:01 UTC 2021


On Thursday, 2 September 2021 at 23:22:57 UTC, deadalnix wrote:
> The right thing is being able to run the unitests of a god damn 
> module easily.

A patch for silly.d that boils down to

```
string targetmodule;
// add "test a single module" to existing getopt flags
if (targetmodule && moduleName!module_ != targetmodule) continue;
```

permits this usage:

```
$ time dub -q test -- --module=testme
  ✓ testme __unittest_L1_C1

Summary: 1 passed, 0 failed in 0 ms

real    0m0.190s
user    0m0.129s
sys     0m0.059s
```

Which tests that single module and ignores the others. This still 
compiles in all the other modules of your project, still compiles 
in their unittest blocks, still runs their module initialization, 
still might rebuild a dub dependency, but in the end it runs only 
the unittest blocks of the chosen module.

Anything short of that is going to be a hacky once-off solution 
that relies on package-specific knowledge that a module's 
unittests don't really depend on that other stuff happening. At 
that level you may as well run 'dmd -main -unittest -run module'.

I think this is the best you're going to get. You can try this 
now by cloning the silly repo, patching it, running `dub 
add-override silly 1.1.1 .` in the repo, and trying out the usage 
above in your dub package that's already set up to use silly.
There's really nothing to the patch but it's here: 
https://run.dlang.io/is/smXgof

>Is this groundhog day?

Well, there's someone in the thread who keeps complaining about 
random dmd flags, which both draws defenses of those flags and 
proposals to change them that won't actually give you the 
workflow you want (like the -unittest= proposal, that still 
requires you to tell dmd about where all your modules are, which 
would still be irritating for dub dependencies).


More information about the Digitalmars-d mailing list