Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
October 12, 2019 selective tests | ||||
---|---|---|---|---|
| ||||
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? 🤔) |
October 12, 2019 Re: selective tests | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Brezeln | 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
|
October 12, 2019 Re: selective tests | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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) |
October 12, 2019 Re: selective tests | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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.
|
October 12, 2019 Re: selective tests | ||||
---|---|---|---|---|
| ||||
Posted in reply to IGotD- | 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. |
Copyright © 1999-2021 by the D Language Foundation