Re: Unit testing a function returning void
On Thursday, 3 November 2022 at 10:26:04 UTC, Imperatorn wrote:
On Thursday, 3 November 2022 at 10:00:27 UTC, Bruno Pagis wrote:
Good morning,
I have the following class:
```
class A {
int[] array;
...
void print() {
writeln("array = ", this.array);
}
}
```
I would like to unit test the print function (yes, I know, not
very useful on the above example since print is merely a
duplicate of writeln...). Is there a way to use assert to test
the output of the print function to stdout? Something like:
```
A myClass= new A;
myClass.array = [1,2];
assert(myClass.print() == "array = [1,2]"); // I know that
print does not return anything so this is wrong, but you get
the idea :-)
```
Thanks.
Just so we understand, do you want to verify that the output is
indeed directed to stdout and not some other stream?
Just for documentation purposes, if you wished to redirect I
believe you could do something like this (untested):
```d
auto original = stdout; // save
stdout.open(newdest, "wt"); // redirect
// do stuff, check newdest
stdout = original; // restore
```
Re: Unit testing a function returning void
On Thursday, 3 November 2022 at 10:00:27 UTC, Bruno Pagis wrote: Good morning, I would like to unit test the print function (yes, I know, not very useful on the above example since print is merely a duplicate of writeln...). Is there a way to use assert to test the output of the print function to stdout? Something like: Just for curiosity: we have this tremendous list of testing libraries https://code.dlang.org/search?q=test Maybe one of them has the 'capture stdout' (https://docs.pytest.org/en/7.1.x/how-to/capture-stdout-stderr.html) feature?
Re: Unit testing a function returning void
On Thu, Nov 03, 2022 at 08:51:52AM -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
> On 11/3/22 03:00, Bruno Pagis wrote:
>
> >void print() {
> > writeln("array = ", this.array);
> >}
>
> Similar to Paul Backus's program but I would try to avoid the file system
> for unit tests when possible. In this case, you can print into a sink, which
> can be useful in other ways as well:
[...]
Alternatively, you can templatize on File to make it swappable with a
mock object:
void myfunc(File = std.stdio.File)(File output = stdout) {
output.writeln(...);
}
unittest {
struct MockFile {
string output;
void writeln(Args...)(Args args) {
output ~= format(args);
}
}
MockFile mock;
myfunc(mock);
assert(mock.output == ...);
}
T
--
"Maybe" is a strange word. When mom or dad says it it means "yes", but when my
big brothers say it it means "no"! -- PJ jr.
Re: Unit testing a function returning void
On 11/3/22 03:00, Bruno Pagis wrote:
>void print() {
> writeln("array = ", this.array);
>}
Similar to Paul Backus's program but I would try to avoid the file
system for unit tests when possible. In this case, you can print into a
sink, which can be useful in other ways as well:
import std.stdio;
class A
{
int[] a;
this(int[] a) { this.a = a; }
void toString(scope void delegate(in char[]) sink) const {
import std.conv : text;
sink("array = ");
sink(this.a.text); // or this.a.to!string
// The following alternative may be a little heavier weight:
// import std.format : formattedWrite;
// sink.formattedWrite!"array = %s"(this.a);
}
void print() {
writeln(this);
}
}
unittest {
import std.file;
A a = new A([1, 2]);
import std.conv : text;
assert(a.text == "array = [1, 2]");
}
void main() {}
toString is the textual representation of the object. If you don't want
the same output for that purpose, you can use a different name from
toString but you have to use an explicit "sink" but I really think the
above is what you want. :)
Ali
Re: Unit testing a function returning void
On Thursday, 3 November 2022 at 10:00:27 UTC, Bruno Pagis wrote:
Good morning,
I have the following class:
```
class A {
int[] array;
...
void print() {
writeln("array = ", this.array);
}
}
```
I would like to unit test the print function (yes, I know, not
very useful on the above example since print is merely a
duplicate of writeln...). Is there a way to use assert to test
the output of the print function to stdout?
The easiest way to do this is to modify the function so it can
output somewhere other than stdout. Then you can have it output
to a file in the unittest, and check the contents of the file to
verify the result.
For example:
```d
import std.stdio;
class A
{
int[] a;
this(int[] a) { this.a = a; }
void print(File output = stdout) {
output.writeln("array = ", this.a);
}
}
unittest {
import std.file;
A a = new A([1, 2]);
a.print(File("test.txt", "wb"));
assert(readText("test.txt") == "array = [1, 2]\n");
}
```
Re: Unit testing a function returning void
On Thursday, 3 November 2022 at 10:00:27 UTC, Bruno Pagis wrote:
Good morning,
I have the following class:
```
class A {
int[] array;
...
void print() {
writeln("array = ", this.array);
}
}
```
I would like to unit test the print function (yes, I know, not
very useful on the above example since print is merely a
duplicate of writeln...). Is there a way to use assert to test
the output of the print function to stdout? Something like:
```
A myClass= new A;
myClass.array = [1,2];
assert(myClass.print() == "array = [1,2]"); // I know that
print does not return anything so this is wrong, but you get
the idea :-)
```
Thanks.
Just so we understand, do you want to verify that the output is
indeed directed to stdout and not some other stream?
Re: Unit testing a function returning void
You could redirect stdout to a file of your choosing and test against that. Although ideally you would instead take as an argument to print some sort of output range or Appender. Then you could test against that instead.
Unit testing a function returning void
Good morning,
I have the following class:
```
class A {
int[] array;
...
void print() {
writeln("array = ", this.array);
}
}
```
I would like to unit test the print function (yes, I know, not
very useful on the above example since print is merely a
duplicate of writeln...). Is there a way to use assert to test
the output of the print function to stdout? Something like:
```
A myClass= new A;
myClass.array = [1,2];
assert(myClass.print() == "array = [1,2]"); // I know that print
does not return anything so this is wrong, but you get the idea
:-)
```
Thanks.
Re: Options for unit testing in D?
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
Re: Options for unit testing in D?
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)
Re: Options for unit testing in D?
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
Re: Options for unit testing in D?
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?
Re: Options for unit testing in D?
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 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
Re: Options for unit testing in D?
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
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
Re: unit testing version statements
On Friday, 22 August 2014 at 09:37:30 UTC, Robert burner Schadek wrote: On Friday, 22 August 2014 at 09:33:10 UTC, Kagamin wrote: Compile and run the tests with different version options. that is not an option This is how version feature is intentionally designed to work
Re: unit testing version statements
On Friday, 22 August 2014 at 09:37:30 UTC, Robert burner Schadek wrote: On Friday, 22 August 2014 at 09:33:10 UTC, Kagamin wrote: Compile and run the tests with different version options. that is not an option Well, that's normally how it would be done. But if you need to test them all with the same build, it's probably easier if the unit tests are in separate modules, since then you can just set the version for the module without having to worry about resetting it. - Jonathan M Davis
Re: unit testing version statements
On Friday, 22 August 2014 at 09:33:10 UTC, Kagamin wrote: Compile and run the tests with different version options. that is not an option
Re: unit testing version statements
Compile and run the tests with different version options.
unit testing version statements
How do I unit test version statements without fixing version in
place forever.
bool fun() {
version(Version1) return true;
else version(Version2) return true;
else return false;
}
version = Version1;
unittest {
assert(fun());
}
version = Version2;
unittest {
assert(fun());
}
unittest {
assert(!fun());
}
version = None; // is there anyway to save and reset the version
Re: Unit testing D module
On Thursday, 26 December 2013 at 09:25:14 UTC, Dfr wrote: If i do not want to unit test whole codebase, because it big enough and all tests take noticeable time to run. So i trying this: dmd -unittest mymodule.d And getting error: "undefined reference to `main'" But i don't want to run 'main' here, just unit test please. Any idea how to test single module without putting 'main' in every module ? the -main flag will do the trick, e.g. dmd -unittest -main mymodule.d Also, if you find you need more control then check out some of the testing frameworks/helpers here: http://code.dlang.org/ (ctrl+f test)
Re: Unit testing D module
On Thursday, 26 December 2013 at 09:25:14 UTC, Dfr wrote: If i do not want to unit test whole codebase, because it big enough and all tests take noticeable time to run. So i trying this: dmd -unittest mymodule.d And getting error: "undefined reference to `main'" But i don't want to run 'main' here, just unit test please. Any idea how to test single module without putting 'main' in every module ? Use the `-main` compiler switch: "Add a default main() function when compiling. This is useful when unittesting a library, as it enables the user to run the unittests in a library without having to manually define an entry-point function." So, dmd -unittest -main mymodule.d
Unit testing D module
If i do not want to unit test whole codebase, because it big enough and all tests take noticeable time to run. So i trying this: dmd -unittest mymodule.d And getting error: "undefined reference to `main'" But i don't want to run 'main' here, just unit test please. Any idea how to test single module without putting 'main' in every module ?
Re: unit testing
- Jonathan M Davis wrote: >LOL. Goodness no. They're done by hand. I'm currently reworking std.datetime's >unit tests, and it's very time consuming (since it's a large module with lots >of tests). I don't know how you'd get a framework to generate what I want >anyway. The fact that D has unit testing built in like it does is fantastic, >but it is fairly simplistic. I'm new to this concept of uni testing. Thanks for the help :)
Re: unit testing
On 2011-03-28 11:29, Ishan Thilina wrote: > @David: > > No, my question was not about running them,but on how that code was > generated. I thought they were auto generated using a unitest framework > :). Your answer clarifies everything. Thank you..! :-) LOL. Goodness no. They're done by hand. I'm currently reworking std.datetime's unit tests, and it's very time consuming (since it's a large module with lots of tests). I don't know how you'd get a framework to generate what I want anyway. The fact that D has unit testing built in like it does is fantastic, but it is fairly simplistic. - Jonathan M Davis
Re: unit testing
@David: No, my question was not about running them,but on how that code was generated. I thought they were auto generated using a unitest framework :). Your answer clarifies everything. Thank you..! :-)
Re: unit testing
On 3/28/11 5:55 PM, Caligo wrote: and how does one do unit testing with GDC? It works fine with DMD, but GDC doesn't do unit testing when -unittest is supplied. -funittest, IIRC. David
Re: unit testing
On Mon, Mar 28, 2011 at 9:34 AM, David Nadlinger wrote: > On 3/28/11 4:23 PM, Ishan Thilina wrote: >> >> I see that almost all of the phobos library files have "unittests". Were >> these >> unit tests were created using some framework? If so, then what is it? >> >> Thank you...! > > No, these unit test were just written by hand while writing the > corresponding pieces of code, and extended after a bug was fixed which they > previously missed. > > Or was your question related to actually running them? > > David > and how does one do unit testing with GDC? It works fine with DMD, but GDC doesn't do unit testing when -unittest is supplied.
Re: unit testing
On 3/28/11 4:23 PM, Ishan Thilina wrote: I see that almost all of the phobos library files have "unittests". Were these unit tests were created using some framework? If so, then what is it? Thank you...! No, these unit test were just written by hand while writing the corresponding pieces of code, and extended after a bug was fixed which they previously missed. Or was your question related to actually running them? David
unit testing
I see that almost all of the phobos library files have "unittests". Were these unit tests were created using some framework? If so, then what is it? Thank you...!
