www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Options for unit testing in D?

reply Mike Brockus <michael squidfarts.com> writes:
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>
Jun 20 2019
next sibling parent XavierAP <n3minis-git yahoo.es> writes:
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
Jun 21 2019
prev sibling parent reply Mike Wey <mike-wey example.com> writes:
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
Jun 21 2019
parent reply Mike Brockus <michael squidfarts.com> writes:
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?
Jun 21 2019
parent reply Paul Backus <snarwin gmail.com> writes:
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
Jun 22 2019
parent reply Mike Brockus <michael squidfarts.com> writes:
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)
Jun 22 2019
parent XavierAP <n3minis-git yahoo.es> writes:
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
Jun 23 2019