Thread overview | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
June 21, 2019 Options for unit testing in D? | ||||
---|---|---|---|---|
| ||||
If you never herd about Meson before: 🤔. https://mesonbuild.com/ I am wondering as to what options are available for a Meson build user when unit testing? What I am trying todo is simply rewrite my C17 project reference templates to D versions so I may show other developers the basic structure of my project if I have a question about something or to influence the idea of Meson with D projects. Excuse the Conan file. As reference: C17 https://github.com/squidfarts/c-example.git https://github.com/squidfarts/c-project.git Dlang https://github.com/squidfarts/d-example.git <working on project version> |
June 21, 2019 Re: Options for unit testing in D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Brockus | On Friday, 21 June 2019 at 04:08:42 UTC, Mike Brockus wrote: > > I am wondering as to what options are available for a Meson build user when unit testing? Unit tests are part of the language in D: https://dlang.org/spec/unittest.html These are compiled when you (or whatever build system you use) pass the argument -unittest to the compiler. > If you never herd about Meson before: > 🤔. https://mesonbuild.com/ D has an "official" build manager, called dub. Of course you're free to use another one you prefer. https://dub.pm/getting_started PS also embedded documentation is part of the language (no need for e.g. doxygen): https://dlang.org/spec/ddoc.html |
June 21, 2019 Re: Options for unit testing in D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Brockus | On 21-06-2019 06:08, Mike Brockus wrote: > If you never herd about Meson before: > 🤔. https://mesonbuild.com/ > > I am wondering as to what options are available for a Meson build user when unit testing? > > What I am trying todo is simply rewrite my C17 project reference templates to D versions so I may show other developers the basic structure of my project if I have a question about something or to influence the idea of Meson with D projects. Excuse the Conan file. > > As reference: > C17 > https://github.com/squidfarts/c-example.git > https://github.com/squidfarts/c-project.git > > Dlang > https://github.com/squidfarts/d-example.git > <working on project version> > If you are using the D unittests in your source you can recompile the same source with `d_unittest: true`, the appstream-generator project does this: https://github.com/ximion/appstream-generator/blob/master/src/asgen/meson.build#L108 Or you can keep the tests separate and compile these test separately like you are doing in your C project. I use this option in the GlibD project: https://github.com/gtkd-developers/GlibD/blob/master/tests/gobject/meson.build -- Mike Wey |
June 21, 2019 Re: Options for unit testing in D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Wey | On Friday, 21 June 2019 at 17:52:43 UTC, Mike Wey wrote:
> On 21-06-2019 06:08, Mike Brockus wrote:
>> [...]
>
> If you are using the D unittests in your source you can recompile the same source with `d_unittest: true`, the appstream-generator project does this: https://github.com/ximion/appstream-generator/blob/master/src/asgen/meson.build#L108
>
> Or you can keep the tests separate and compile these test separately like you are doing in your C project. I use this option in the GlibD project: https://github.com/gtkd-developers/GlibD/blob/master/tests/gobject/meson.build
So to use D 'unittest' I am required to include the main.d module file in the tester executable?
|
June 22, 2019 Re: Options for unit testing in D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Brockus | On Friday, 21 June 2019 at 22:35:55 UTC, Mike Brockus wrote:
> On Friday, 21 June 2019 at 17:52:43 UTC, Mike Wey wrote:
>> On 21-06-2019 06:08, Mike Brockus wrote:
>>> [...]
>>
>> If you are using the D unittests in your source you can recompile the same source with `d_unittest: true`, the appstream-generator project does this: https://github.com/ximion/appstream-generator/blob/master/src/asgen/meson.build#L108
>>
>> Or you can keep the tests separate and compile these test separately like you are doing in your C project. I use this option in the GlibD project: https://github.com/gtkd-developers/GlibD/blob/master/tests/gobject/meson.build
>
> So to use D 'unittest' I am required to include the main.d module file in the tester executable?
If you pass the `-main` flag to the compiler when building your tester executable, it will add an empty main function for you. For example:
dmd -unittest -main mymodule.d
|
June 23, 2019 Re: Options for unit testing in D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Backus | On Saturday, 22 June 2019 at 13:51:10 UTC, Paul Backus wrote:
> On Friday, 21 June 2019 at 22:35:55 UTC, Mike Brockus wrote:
>> On Friday, 21 June 2019 at 17:52:43 UTC, Mike Wey wrote:
>>> On 21-06-2019 06:08, Mike Brockus wrote:
>>>> [...]
>>>
>>> If you are using the D unittests in your source you can recompile the same source with `d_unittest: true`, the appstream-generator project does this: https://github.com/ximion/appstream-generator/blob/master/src/asgen/meson.build#L108
>>>
>>> Or you can keep the tests separate and compile these test separately like you are doing in your C project. I use this option in the GlibD project: https://github.com/gtkd-developers/GlibD/blob/master/tests/gobject/meson.build
>>
>> So to use D 'unittest' I am required to include the main.d module file in the tester executable?
>
> If you pass the `-main` flag to the compiler when building your tester executable, it will add an empty main function for you. For example:
>
> dmd -unittest -main mymodule.d
I think we made a lot of progress, suddenly it's working and I don't need to include main. Is there a way to indicate based on console output that one executable is the tester and the other is the application?
test_exe = executable('test_exe',
sources: [ 'test.d' ],
d_args: [ '-main' ],
d_unittest: true,
include_directories: exe_dir)
|
June 23, 2019 Re: Options for unit testing in D? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Brockus | On Sunday, 23 June 2019 at 01:26:29 UTC, Mike Brockus wrote: > > I think we made a lot of progress, suddenly it's working and I don't need to include main. Is there a way to indicate based on console output that one executable is the tester and the other is the application? unittest blocks are skipped completely by the compiler when the -unittest command line option is not passed. So you can leave unittest code embedded in between the rest (specially for proper unit tests of functions and classes) and there is no need to worry about file separation. Even when you write a separate file with tests, all its code inside unittest blocks can be skipped for the compiler. In the case of dub, it has a dedicated option, "dub test" instead of "dub build" or "dub run" https://dub.pm/commandline.html#test |
Copyright © 1999-2021 by the D Language Foundation