Is it possible to execute only certain modules or tests which are defined in certain directories?

For example, in go one can run "go test ./XYZ" to execute ony tests in ./XYZ or "go test ./..." to execute all the tests in and under the current directory.

Please don't get me wrong, i do not wish to start a discussion about doing things the "go way". I am asking if there is a way to achieve a similar result with dub (or maybe without dub?
🤔)

On Saturday, October 12, 2019 2:18:02 AM MDT Martin Brezeln via Digitalmars- d-learn wrote:
> Is it possible to execute only certain modules or tests which are defined in certain directories?
>
> For example, in go one can run "go test ./XYZ" to execute ony tests in ./XYZ or "go test ./..." to execute all the tests in and under the current directory.
>
> Please don't get me wrong, i do not wish to start a discussion
> about doing things the "go way". I am asking if there is a way to
> achieve a similar result with dub (or maybe without dub?
> 🤔)

The default test runner does not support running only some of the tests. It simply runs all of the unittest blocks in the binary prior to running main, and tests only get skipped when they're either not compiled in or when a previous unittest block in that module failed.

You could set up your build so that you had targets which only compiled specific directories so that the only unit tests that were run were the ones in those directories, but I don't think that it's possible to do anything like that with dub. Certainly, if it is, it would be a royal pain to set up.

Really, if you want to control which tests get run instead of simply always running them all, then you'll need to use an alternate test runner which supports that. There are a few test runners available on code.dlang.org, and I expect that at least one of them supports that (probably multiple do).

- Jonathan M Davis

On Saturday, 12 October 2019 at 09:52:59 UTC, Jonathan M Davis wrote:
> You could set up your build so that you had targets which only compiled specific directories so that the only unit tests that were run were the ones in those directories, but I don't think that it's possible to do anything like that with dub. Certainly, if it is, it would be a royal pain to set up.

I think you can do it with sub packages:

dub.sdl
```
name "bread-and-butter"
description "the best thing since slided bread"
sourceFiles ""
dependency "bread-and-butter:bread"  version="*"
dependency "bread-and-butter:butter" version="*"

subPackage {
    name "bread"
    sourceFiles "source/bread/*.d"

}

subPackage {
    name "butter"
    sourcePaths "source/butter"
    dependency "bread-and-butter:bread" version="*"
}
```

Then you can run tests like:

```
dub test bread-and-butter
dub test bread-and-butter:bread
dub test bread-and-butter:butter
```

An annoying thing about sub packages though is that you may have to duplicate lots of settings.
(hint hint https://forum.dlang.org/thread/fppszpfvbnvioeiakfjv@forum.dlang.org)

On Saturday, 12 October 2019 at 09:52:59 UTC, Jonathan M Davis wrote:
> On Saturday, October 12, 2019 2:18:02 AM MDT Martin Brezeln via Digitalmars- d-learn wrote:
>> Is it possible to execute only certain modules or tests which are defined in certain directories?
>>
>> For example, in go one can run "go test ./XYZ" to execute ony tests in ./XYZ or "go test ./..." to execute all the tests in and under the current directory.
>>
>> Please don't get me wrong, i do not wish to start a discussion
>> about doing things the "go way". I am asking if there is a way to
>> achieve a similar result with dub (or maybe without dub?
>> 🤔)
>
> The default test runner does not support running only some of the tests. It simply runs all of the unittest blocks in the binary prior to running main, and tests only get skipped when they're either not compiled in or when a previous unittest block in that module failed.
>
> You could set up your build so that you had targets which only compiled specific directories so that the only unit tests that were run were the ones in those directories, but I don't think that it's possible to do anything like that with dub. Certainly, if it is, it would be a royal pain to set up.
>
> Really, if you want to control which tests get run instead of simply always running them all, then you'll need to use an alternate test runner which supports that. There are a few test runners available on code.dlang.org, and I expect that at least one of them supports that (probably multiple do).
>
> - Jonathan M Davis

This would be helpful. About all C++ unit test frameworks have named test and you can select a specific one or several in the command line. Very useful when you work on a specific test and other tests take some time to finish.

having

unittest OptionalName
{
   ...
}

would actually help a lot. I don't think this would be very difficult to implement and wouldn't break anything.

On Saturday, 12 October 2019 at 13:50:46 UTC, IGotD- wrote:
> On Saturday, 12 October 2019 at 09:52:59 UTC, Jonathan M Davis wrote:
>> [...]
>
> This would be helpful. About all C++ unit test frameworks have named test and you can select a specific one or several in the command line. Very useful when you work on a specific test and other tests take some time to finish.
>
> having
>
> unittest OptionalName
> {
>    ...
> }
>
> would actually help a lot. I don't think this would be very difficult to implement and wouldn't break anything.

It wouldn't be hard, but someone would need to write a DIP for it. In the meantime you can use https://github.com/atilaneves/unit-threaded.