www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Utah Valley University teaches D (using TDPL)

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
http://uvu.freshsources.com/page9/page7/files/Syllabus4450.html

Andrei
Nov 15 2010
next sibling parent David Gileadi <gileadis NSPMgmail.com> writes:
On 11/15/10 2:00 PM, Andrei Alexandrescu wrote:
 http://uvu.freshsources.com/page9/page7/files/Syllabus4450.html

 Andrei

I had a class from Chuck; he introduced me to D. He's an excellent teacher.
Nov 15 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 [Good Stuff=E2=84=A2]

Awesome! -- = Simen
Nov 15 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:

 http://uvu.freshsources.com/page9/page7/files/Syllabus4450.html

This is good. Despite its bugs/unfinished parts D2 is a good language to teach certain kinds of lower level programming (and some OOP too). This is the page of the resources of the course: http://uvu.freshsources.com/page9/page7/page7.html This is the D Homework: http://uvu.freshsources.com/page9/page7/files/D%20Homework.docx It contains: Implement a deque in D using two dynamic arrays, as depicted above. The following functions should be present: push_front(x) push_back(x) pop_front() pop_back() at(uint pos) back() front() size() I see two small problems there: - uint used instead of size_t - Names like_this instead of the D idiom likeThis. He also gives a quite useful unittest that the student implementation must pass, this is a good usage of unittests. The unit test ends like this: ... writeln("unit test passed"); } Indeed, a person needs feedback that the unittests have run (and have succeed), I have used similar things in my dlbs1 (but more refined). This kind of need for feedback is so natural that something like that will be better somehow done on default by D. Bye, bearophile
Nov 15 2010
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
bearophile Wrote:
 
 He also gives a quite useful unittest that the student implementation must
pass, this is a good usage of unittests. The unit test ends like this:
 
 ...
     writeln("unit test passed");
 }
 
 Indeed, a person needs feedback that the unittests have run (and have
succeed), I have used similar things in my dlbs1 (but more refined). This kind
of need for feedback is so natural that something like that will be better
somehow done on default by D.

I'd like unit tests to be optionally named: unittest("name"). The rest could then be done in library code.
Nov 16 2010
next sibling parent reply Gide Nwawudu <gide btinternet.com> writes:
On Tue, 16 Nov 2010 10:54:50 -0800, Jonathan M Davis
<jmdavisProg gmx.com> wrote:

On Tuesday, November 16, 2010 07:53:01 Sean Kelly wrote:
 bearophile Wrote:
 He also gives a quite useful unittest that the student implementation
 must pass, this is a good usage of unittests. The unit test ends like
 this:
 
 ...
 
     writeln("unit test passed");
 
 }
 
 Indeed, a person needs feedback that the unittests have run (and have
 succeed), I have used similar things in my dlbs1 (but more refined).
 This kind of need for feedback is so natural that something like that
 will be better somehow done on default by D.

I'd like unit tests to be optionally named: unittest("name"). The rest could then be done in library code.

That would indeed be great. With that done, it could become possible to run unit tests by name (though that would likely mean more changes for the compiler) in an IDE or whatnot. There's at least one bug report suggesting it, IIRC, though I think that it was suggested that they be named without the quotes. unittest(name) should probably translate to something like unittest_name in whatever scope it's in. In any case, it's a good enhancement request that hasn't come to fruition yet. Most of the rest (if not all of it) could indeed be done in a library. Right now unit tests follow the unix convention of saying nothing on success, which I think is best for the current set up - particularly when it's not all that hard to add code yourself which prints out success if you really want it to. - Jonathan M Davis

Already requested, see http://d.puremagic.com/issues/show_bug.cgi?id=2749 Gide
Nov 16 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 16/11/2010 21:11, Gide Nwawudu wrote:
 On Tue, 16 Nov 2010 10:54:50 -0800, Jonathan M Davis
 <jmdavisProg gmx.com>  wrote:

 On Tuesday, November 16, 2010 07:53:01 Sean Kelly wrote:
 bearophile Wrote:
 He also gives a quite useful unittest that the student implementation
 must pass, this is a good usage of unittests. The unit test ends like
 this:

 ...

      writeln("unit test passed");

 }

 Indeed, a person needs feedback that the unittests have run (and have
 succeed), I have used similar things in my dlbs1 (but more refined).
 This kind of need for feedback is so natural that something like that
 will be better somehow done on default by D.

I'd like unit tests to be optionally named: unittest("name"). The rest could then be done in library code.

That would indeed be great. With that done, it could become possible to run unit tests by name (though that would likely mean more changes for the compiler) in an IDE or whatnot. There's at least one bug report suggesting it, IIRC, though I think that it was suggested that they be named without the quotes. unittest(name) should probably translate to something like unittest_name in whatever scope it's in. In any case, it's a good enhancement request that hasn't come to fruition yet. Most of the rest (if not all of it) could indeed be done in a library. Right now unit tests follow the unix convention of saying nothing on success, which I think is best for the current set up - particularly when it's not all that hard to add code yourself which prints out success if you really want it to. - Jonathan M Davis

Already requested, see http://d.puremagic.com/issues/show_bug.cgi?id=2749 Gide

I also agree having named unittests might be quite useful. I'm not sure about the nesting though, its seems to me using the D module itself as nesting is perfectly fine. -- Bruno Medeiros - Software Engineer
Nov 18 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 Most of the rest (if not all of it) could indeed be done in a library.

I am not sure it could be done nicely too :-)
 Right now 
 unit tests follow the unix convention of saying nothing on success,

That's an usability failure. Humans expect feedback, because you can't tell apart "unittests run and succeed" from "unittests not even run". That Unix convention is bad here. And Unix commands sometimes have a -v (verbose) command that gives feedback, while D unittests don't have this option.
 particularly when it's not all that hard 
 to add code yourself which prints out success if you really want it to.

It's also not hard to define global functions, wrapped in a version(unittest){}, to replace the need of the unittest keyword (unittest becomes a version ID). Bye, bearophile
Nov 16 2010
next sibling parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
bearophile wrote:

 Jonathan M Davis:
 
 Most of the rest (if not all of it) could indeed be done in a library.

I am not sure it could be done nicely too :-)
 Right now
 unit tests follow the unix convention of saying nothing on success,

That's an usability failure. Humans expect feedback, because you can't tell apart "unittests run and succeed" from "unittests not even run". That Unix convention is bad here. And Unix commands sometimes have a -v (verbose) command that gives feedback, while D unittests don't have this option.

Actually the unix convention is to give exit code 0 as an indicator of success, so there is feedback. It is very usable for scripting. But with the change Sean suggested - and I assume an extension point in druntime - there would be enough for a more human friendly tool to be built on top of the current D unittesting system.
 particularly when it's not all that hard
 to add code yourself which prints out success if you really want it to.

It's also not hard to define global functions, wrapped in a version(unittest){}, to replace the need of the unittest keyword (unittest becomes a version ID). Bye, bearophile

Nov 17 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Lutger Blijdestijn:

 Actually the unix convention is to give exit code 0 as an indicator of 
 success, so there is feedback. It is very usable for scripting.

But currently something like that is not present in the D unittest system.
 But with the 
 change Sean suggested - and I assume an extension point in druntime - there 
 would be enough for a more human friendly tool to be built on top of the 
 current D unittesting system.

We'll see. Bye, bearophile
Nov 17 2010
next sibling parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
bearophile wrote:

 Lutger Blijdestijn:
 
 Actually the unix convention is to give exit code 0 as an indicator of
 success, so there is feedback. It is very usable for scripting.

But currently something like that is not present in the D unittest system.

rdmd --main -unittest somemodule.d
Nov 17 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:
 Lutger Blijdestijn:
 
 Actually the unix convention is to give exit code 0 as an indicator of 
 success, so there is feedback. It is very usable for scripting.

But currently something like that is not present in the D unittest system.

Yes, it is. Unit test failures return a non-zero exit code.
Nov 26 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 Yes, it is. Unit test failures return a non-zero exit code.

I see, good. But real unit test systems don't just return that value, they give a more visible feedback, like the number of failed/passed tests. One line of text that shows those numbers is a good start. Bye, bearophile
Nov 26 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
 But real unit test systems don't just return that value, they give a more
visible feedback, like the number of failed/passed tests. One line of text that
shows those numbers is a good start.

Or maybe that's not the job of a compiler... Bye, bearophile
Nov 26 2010
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:
 Walter:
 
 Yes, it is. Unit test failures return a non-zero exit code.

I see, good.

I wish you'd check these things before confidently posting incorrect assertions about how D behaves.
Nov 26 2010
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Jonathan M Davis wrote:
 I'm a firm believer that D unit tests should not change how they fundamentally 
 work at this point. I don't _want_ it to report the number of tests that
passed. 

That's right. The number that fail is completely useless window dressing.
 That information is not at all useful. And if I want to do something like set
up 
 something to run dmd periodically and report only when the tests start
failing, 
 then the current situation is perfect.
 
 I _do_ think that the unit testing stuff should be expanded to have named unit 
 tests and do whatever is necessary to make it possible for external tools to
run 
 the unit tests. Then you could have an external tool that did things like only 
 run specific unit tests and report which tests succeeded and which failed.
 
 So, I do think that it should be possible to build external tools on D's unit 
 testing framework, but I think that it's quite good as it is now, and I
wouldn't 
 want to see it drastically changed.
 
 The two changes that I want to see to the current framework are
 
 1. Make it so that every unittest block runs in a module instead of them 
 stopping once one failed. The current situation is better than stopping _all_ 
 unittest blocks once a single test fails, but it's still not granular enough.
I 
 believe that this change is planned, but work has to be done to make it 
 possible, and that work hasn't been done yet.

I believe that is the current behavior. For a time, it kept getting broken by changes to druntime, so it may be broken yet again, but that is the way it is supposed to work.
 2. Make it possible to name unittest blocks. This would make exceptions that 
 escape unittest blocks _far_ more useful. Names like unittest45 really aren't 
 useful at all. I can't even figure out how it does the numbering.

If the line numbers given out are incorrect, those are compiler bugs and I'd like to get them fixed.
 Also, having named unittest blocks would be a necessity for properly allowing 

I don't really know how that would work.
 I do _not_ want to see D programs printing out anything more than they do when 
 running unit tests. I'm totally open to external tools which do more (it would 
 particularly good for IDEs to be able to run unittest blocks individually),
but 
 I do not want to see the basic framework change how it prints feedback on test 
 successes and failures. It works great as it is now.

Yes, and if anyone wants more, a writefln("your message here") works just fine.
Nov 26 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 26 November 2010 17:17:56 bearophile wrote:
 Walter:
 Yes, it is. Unit test failures return a non-zero exit code.

I see, good. But real unit test systems don't just return that value, they give a more visible feedback, like the number of failed/passed tests. One line of text that shows those numbers is a good start.

I'm a firm believer that D unit tests should not change how they fundamentally work at this point. I don't _want_ it to report the number of tests that passed. That information is not at all useful. And if I want to do something like set up something to run dmd periodically and report only when the tests start failing, then the current situation is perfect. I _do_ think that the unit testing stuff should be expanded to have named unit tests and do whatever is necessary to make it possible for external tools to run the unit tests. Then you could have an external tool that did things like only run specific unit tests and report which tests succeeded and which failed. So, I do think that it should be possible to build external tools on D's unit testing framework, but I think that it's quite good as it is now, and I wouldn't want to see it drastically changed. The two changes that I want to see to the current framework are 1. Make it so that every unittest block runs in a module instead of them stopping once one failed. The current situation is better than stopping _all_ unittest blocks once a single test fails, but it's still not granular enough. I believe that this change is planned, but work has to be done to make it possible, and that work hasn't been done yet. 2. Make it possible to name unittest blocks. This would make exceptions that escape unittest blocks _far_ more useful. Names like unittest45 really aren't useful at all. I can't even figure out how it does the numbering. Also, having named unittest blocks would be a necessity for properly allowing external tools to run the unit tests. I do _not_ want to see D programs printing out anything more than they do when running unit tests. I'm totally open to external tools which do more (it would particularly good for IDEs to be able to run unittest blocks individually), but I do not want to see the basic framework change how it prints feedback on test successes and failures. It works great as it is now. - Jonathan M Davis
Nov 26 2010
prev sibling next sibling parent Don <nospam nospam.com> writes:
Jonathan M Davis wrote:
 On Tuesday, November 16, 2010 13:33:54 bearophile wrote:
 Jonathan M Davis:
 Most of the rest (if not all of it) could indeed be done in a library.


That would depend on what you're trying to do. Printing test success or failure is as simple as adding the approprate scope statement to the beginning of each unittest block. A bit tedious perhaps, but not hard.
 Right now
 unit tests follow the unix convention of saying nothing on success,

apart "unittests run and succeed" from "unittests not even run". That Unix convention is bad here. And Unix commands sometimes have a -v (verbose) command that gives feedback, while D unittests don't have this option.

I'm afraid that I have to disagree there. Having all of the successes print out would, in many cases, just be useless output flooding the console. I have no problem with making it possible for unit tests to report success, but I wouldn't want that to be the default. It's quite clear when a test fails, and that's what is necessary in order to fix test failures. I can see why a beginner might want the positive feedback that a test has succeeded, but personally, I would just find it annoying. The only real advantage would be that it would indicate where in the unit tests the program was, and that's only particularly important if you have a _lot_ of them and they take a long time to run.

I think: "%d unit tests passed in %d modules" would be enough.
Nov 18 2010
prev sibling parent reply Fawzi Mohamed <fawzi gmx.ch> writes:
On 18-nov-10, at 09:11, Don wrote:

 Jonathan M Davis wrote:
 On Tuesday, November 16, 2010 13:33:54 bearophile wrote:
 Jonathan M Davis:
 Most of the rest (if not all of it) could indeed be done in a  
 library.


success or failure is as simple as adding the approprate scope statement to the beginning of each unittest block. A bit tedious perhaps, but not hard.
 Right now
 unit tests follow the unix convention of saying nothing on success,

can't tell apart "unittests run and succeed" from "unittests not even run". That Unix convention is bad here. And Unix commands sometimes have a -v (verbose) command that gives feedback, while D unittests don't have this option.

successes print out would, in many cases, just be useless output flooding the console. I have no problem with making it possible for unit tests to report success, but I wouldn't want that to be the default. It's quite clear when a test fails, and that's what is necessary in order to fix test failures. I can see why a beginner might want the positive feedback that a test has succeeded, but personally, I would just find it annoying. The only real advantage would be that it would indicate where in the unit tests the program was, and that's only particularly important if you have a _lot_ of them and they take a long time to run.

I think: "%d unit tests passed in %d modules" would be enough.

This was already discussed, I think that optimal solution would be to have a testing function a bit like tangos, the testing functions knows how the module is called. Tango one always prints the module, but that is easy to change. What I use is my own testing framework, in it i have defined as default main function that checks commandline arguments, so that one can for example pass --print-level=error and see only the errors... See http://dsource.org/projects/blip/wiki/BlipOverview for an example of using it. This means having a special file to compile, that generates an executable dedicated to testing, but this maps well to how I do tests. In fact I often keep the tests separated from the code, I even hide them behind templates to avoid excessive template instantiation in some cases because they are large and would slow down the compilation... The current default unittest function runs very early (before main), so it is not possible to use that and use commandline arguments (which is "correct" because in the current model unittests can be activated for *any* executable, and should not disturb its run). It should be possible to write a test function that just sets up things for a later real unittest run that starts from main and can parse the commandline arguments, thus solving all these discussions... Fawzi
Nov 18 2010
parent Sean Kelly <sean invisibleduck.org> writes:
Fawzi Mohamed <fawzi gmx.ch> wrote:
 On 18-nov-10, at 09:11, Don wrote:
 
 Jonathan M Davis wrote:
 On Tuesday, November 16, 2010 13:33:54 bearophile wrote:
 Jonathan M Davis:
 Most of the rest (if not all of it) could indeed be done in a 
 library.






success or failure is as simple as adding the approprate scope >> statement to the beginning of each unittest block. A bit tedious
 perhaps, but not hard.
 Right now
 unit tests follow the unix convention of saying nothing on
 success,

 can't tell



 That Unix



(verbose) command that gives feedback, while D unittests don't have this >>> option.

successes print out would, in many cases, just be useless output
 flooding the console. I have no problem with making it possible
 for  >> unit tests to report success, but I wouldn't want that
 to be the  >> default. It's quite clear when a test fails, and
 that's what is  >> necessary in order to fix test failures.


test has succeeded, but personally, I would just find it annoying. >> The only real advantage would be that it would indicate where in >> the unit tests the program was, and that's only particularly >> important if you have a _lot_ of them and they take a long time to >> run.

I think: "%d unit tests passed in %d modules" would be enough.

This was already discussed, I think that optimal solution would be to have a testing function a bit like tangos, the testing functions knows how the module is called. Tango one always prints the module, but that is easy to change. What I use is my own testing framework, in it i have defined as default main function that checks commandline arguments, so that one can for example pass --print-level=error and see only the errors... See http://dsource.org/projects/blip/wiki/BlipOverview for an example of using it. This means having a special file to compile, that generates an executable dedicated to testing, but this maps well to how I do tests. In fact I often keep the tests separated from the code, I even hide them behind templates to avoid excessive template instantiation in some cases because they are large and would slow down the compilation... The current default unittest function runs very early (before main), so it is not possible to use that and use commandline arguments (which is "correct" because in the current model unittests can be activated for *any* executable, and should not disturb its run). It should be possible to write a test function that just sets up things for a later real unittest run that starts from main and can parse the commandline arguments, thus solving all these discussions...

You can access the commandline args via Runtime.args. This works within unittests.
Nov 21 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, November 16, 2010 07:53:01 Sean Kelly wrote:
 bearophile Wrote:
 He also gives a quite useful unittest that the student implementation
 must pass, this is a good usage of unittests. The unit test ends like
 this:
 
 ...
 
     writeln("unit test passed");
 
 }
 
 Indeed, a person needs feedback that the unittests have run (and have
 succeed), I have used similar things in my dlbs1 (but more refined).
 This kind of need for feedback is so natural that something like that
 will be better somehow done on default by D.

I'd like unit tests to be optionally named: unittest("name"). The rest could then be done in library code.

That would indeed be great. With that done, it could become possible to run unit tests by name (though that would likely mean more changes for the compiler) in an IDE or whatnot. There's at least one bug report suggesting it, IIRC, though I think that it was suggested that they be named without the quotes. unittest(name) should probably translate to something like unittest_name in whatever scope it's in. In any case, it's a good enhancement request that hasn't come to fruition yet. Most of the rest (if not all of it) could indeed be done in a library. Right now unit tests follow the unix convention of saying nothing on success, which I think is best for the current set up - particularly when it's not all that hard to add code yourself which prints out success if you really want it to. - Jonathan M Davis
Nov 16 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, November 16, 2010 13:33:54 bearophile wrote:
 Jonathan M Davis:
 Most of the rest (if not all of it) could indeed be done in a library.

I am not sure it could be done nicely too :-)

That would depend on what you're trying to do. Printing test success or failure is as simple as adding the approprate scope statement to the beginning of each unittest block. A bit tedious perhaps, but not hard.
 Right now
 unit tests follow the unix convention of saying nothing on success,

That's an usability failure. Humans expect feedback, because you can't tell apart "unittests run and succeed" from "unittests not even run". That Unix convention is bad here. And Unix commands sometimes have a -v (verbose) command that gives feedback, while D unittests don't have this option.

I'm afraid that I have to disagree there. Having all of the successes print out would, in many cases, just be useless output flooding the console. I have no problem with making it possible for unit tests to report success, but I wouldn't want that to be the default. It's quite clear when a test fails, and that's what is necessary in order to fix test failures. I can see why a beginner might want the positive feedback that a test has succeeded, but personally, I would just find it annoying. The only real advantage would be that it would indicate where in the unit tests the program was, and that's only particularly important if you have a _lot_ of them and they take a long time to run. Adding named unit tests and making it possible to call locate and call unit tests functions externally would make it possible to have an IDE or some other external tool deal with unit test successes and failures in a manner closer to what you're looking for, and I think that that sort of thing would be a definite step forward, but what we have works quite well. I think that extensions to it (like adding names to unit tests) would be great, but the only major change that I can think of which really needs to be made (rather than an extension) would be to make it so that all unittest blocks in a module run independently so that they all run regardless of whether any others fail (and I think that that change is supposed to be being done at some point). Making changes such as making unittest blocks print on success is not something that I would consider a good change (though making it possible wouldn't necessarily be bad).
 particularly when it's not all that hard
 to add code yourself which prints out success if you really want it to.

It's also not hard to define global functions, wrapped in a version(unittest){}, to replace the need of the unittest keyword (unittest becomes a version ID).

Almost, but not quite. -unittest also enables assertions if they would otherwise be disabled, which a simple version couldn't do. - Jonathan M Davis
Nov 16 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday 18 November 2010 04:47:43 Bruno Medeiros wrote:
 On 16/11/2010 21:11, Gide Nwawudu wrote:
 On Tue, 16 Nov 2010 10:54:50 -0800, Jonathan M Davis
 
 <jmdavisProg gmx.com>  wrote:
 On Tuesday, November 16, 2010 07:53:01 Sean Kelly wrote:
 bearophile Wrote:
 He also gives a quite useful unittest that the student implementation
 must pass, this is a good usage of unittests. The unit test ends like
 this:
 
 ...
 
      writeln("unit test passed");
 
 }
 
 Indeed, a person needs feedback that the unittests have run (and have
 succeed), I have used similar things in my dlbs1 (but more refined).
 This kind of need for feedback is so natural that something like that
 will be better somehow done on default by D.

I'd like unit tests to be optionally named: unittest("name"). The rest could then be done in library code.

That would indeed be great. With that done, it could become possible to run unit tests by name (though that would likely mean more changes for the compiler) in an IDE or whatnot. There's at least one bug report suggesting it, IIRC, though I think that it was suggested that they be named without the quotes. unittest(name) should probably translate to something like unittest_name in whatever scope it's in. In any case, it's a good enhancement request that hasn't come to fruition yet. Most of the rest (if not all of it) could indeed be done in a library. Right now unit tests follow the unix convention of saying nothing on success, which I think is best for the current set up - particularly when it's not all that hard to add code yourself which prints out success if you really want it to. - Jonathan M Davis

Already requested, see http://d.puremagic.com/issues/show_bug.cgi?id=2749 Gide

I also agree having named unittests might be quite useful. I'm not sure about the nesting though, its seems to me using the D module itself as nesting is perfectly fine.

I see no point in nesting. Name unit tests, however, would make stack traces from unit tests actually useable (since you'd know which test they were from when they weren't actually assertion failures in the tests themselves which give you a line number in the tests), and it helps open the doors for allowing external tools to access them directly. - Jonathan M Davis
Nov 18 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 26 November 2010 18:52:59 Walter Bright wrote:
 Jonathan M Davis wrote:
 I'm a firm believer that D unit tests should not change how they
 fundamentally work at this point. I don't _want_ it to report the number
 of tests that passed.

That's right. The number that fail is completely useless window dressing.
 That information is not at all useful. And if I want to do something like
 set up something to run dmd periodically and report only when the tests
 start failing, then the current situation is perfect.
 
 I _do_ think that the unit testing stuff should be expanded to have named
 unit tests and do whatever is necessary to make it possible for external
 tools to run the unit tests. Then you could have an external tool that
 did things like only run specific unit tests and report which tests
 succeeded and which failed.
 
 So, I do think that it should be possible to build external tools on D's
 unit testing framework, but I think that it's quite good as it is now,
 and I wouldn't want to see it drastically changed.
 
 The two changes that I want to see to the current framework are
 
 1. Make it so that every unittest block runs in a module instead of them
 stopping once one failed. The current situation is better than stopping
 _all_ unittest blocks once a single test fails, but it's still not
 granular enough. I believe that this change is planned, but work has to
 be done to make it possible, and that work hasn't been done yet.

I believe that is the current behavior. For a time, it kept getting broken by changes to druntime, so it may be broken yet again, but that is the way it is supposed to work.

It's not. This program import std.stdio; bool func() { return false; } void main() { } unittest { writeln("test 1"); assert(func()); } unittest { writeln("test 2"); } prints test 1 core.exception.AssertError test(15): unittest failure ---------------- ./test(onAssertErrorMsg+0x34) [0x808c0f4] ./test(onUnittestErrorMsg+0x18) [0x807f3b8] ./test(_d_unittestm+0x22) [0x807d252] ./test(void test.__unittest_fail(int)) [0x807acfa] ./test(void test.__unittest1()) [0x807ac3b] ./test(void test.__modtest()) [0x807ace0] ./test(extern (C) bool core.runtime.runModuleUnitTests()) [0x807f56c] ./test(_D6object10ModuleInfo7opApplyFMDFKPS6object10ModuleInfoZiZi+0x41) [0x807cd7d] ./test(runModuleUnitTests+0x87) [0x807f487] ./test(extern (C) int rt.dmain2.main(int, char**)) [0x807d448] ./test(extern (C) int rt.dmain2.main(int, char**)) [0x807d370] ./test(main+0x96) [0x807d316] /usr/lib32/libc.so.6(__libc_start_main+0xe6) [0xf75b7c76] ./test() [0x807ab51] The second unittest block is never run. I believe that the last time that this got discussed on the Phobos list, Sean said that some fundamental changes had to be made to either dmd or druntime (I _think_ it was dmd, but I'm not sure) to make it possible to run subsequent unit tests in a module after one of them has failed. If a test in a module fails, then the tests in other modules run, but not the rest of the tests in the module that had the failure.
 2. Make it possible to name unittest blocks. This would make exceptions
 that escape unittest blocks _far_ more useful. Names like unittest45
 really aren't useful at all. I can't even figure out how it does the
 numbering.

If the line numbers given out are incorrect, those are compiler bugs and I'd like to get them fixed.

Not the line number. I'm talking about the function name that you get stack traces. Take this program for instance: void func() { throw new Exception("An exception threw."); } void main() { } unittest { func(); } If you run the unit tests, you get object.Exception: An exception threw. ---------------- ./test(void test.func()) [0x80599fe] ./test(void test.__unittest1()) [0x8059a10] ./test(void test.__modtest()) [0x8059a1c] ./test(extern (C) bool core.runtime.runModuleUnitTests()) [0x805dcdc] ./test(_D6object10ModuleInfo7opApplyFMDFKPS6object10ModuleInfoZiZi+0x41) [0x805ba9d] ./test(runModuleUnitTests+0x87) [0x805dbf7] ./test(extern (C) int rt.dmain2.main(int, char**)) [0x805c168] ./test(extern (C) int rt.dmain2.main(int, char**)) [0x805c090] ./test(main+0x96) [0x805c036] /usr/lib32/libc.so.6(__libc_start_main+0xe6) [0xf7595c76] ./test() [0x8059921] Notic __unittest1(). Here, there's only one unit test, so it's not a big deal, but once you have a lot of them, it's not really feasible to associate that function name with a unittest block. If the unittest blocks were named, something like this unitest(mytest) { } then you could get a stack trace like this object.Exception: An exception threw. ---------------- ./test(void test.func()) [0x80599fe] ./test(void test.__unittest_mytest()) [0x8059a10] ./test(void test.__modtest()) [0x8059a1c] ./test(extern (C) bool core.runtime.runModuleUnitTests()) [0x805dcdc] ./test(_D6object10ModuleInfo7opApplyFMDFKPS6object10ModuleInfoZiZi+0x41) [0x805ba9d] ./test(runModuleUnitTests+0x87) [0x805dbf7] ./test(extern (C) int rt.dmain2.main(int, char**)) [0x805c168] ./test(extern (C) int rt.dmain2.main(int, char**)) [0x805c090] ./test(main+0x96) [0x805c036] /usr/lib32/libc.so.6(__libc_start_main+0xe6) [0xf7595c76] ./test() [0x8059921] With that stack trace, I can easily determine which test threw the exception. It's not a problem with assertions within the test - since they'll give the file and line number of the assertion in the test - but if any function called by the test throws an exception for whatever reason (including assertions in contracts), then you get a stack trace that borders on useless, because you can't easily determine which unittest block threw the exception. With named unittest blocks, that problem can be fixed. As it stands, I don't even know how the number for the unittest is picked. It does not appear that __unittestX() necessarily corresponds to the Xth unit test in a module lexographically. Named unit tests are really the way that the problem should be fixed. I'm not saying that naming unittest blocks should be mandatory, but I think that it should be possible. Unnamed unittest blocks result in functions with names like __unittest1() like they do now, whereas named unittest blocks would result in names like __unittest_testname() where testname is the name of the unittest block. It would make stack traces far easier to deal with, and if external tools are ever going to have any hope of calling unit test functions, then I think that it's a necessity
  > Also, having named unittest blocks would be a necessity for properly
  > allowing
 
 external tools to run the unit tests.
 
 I don't really know how that would work.

I'm not sure either. But ideally, it would be possible to have an external tool run a program which runs all of the static constructors and whatever else has to be run before the unittest blocks can run, and then specifically run each unittest block that it wants to, in whatever order it wants to, without necessarily running all of them. For instance, if you use JUnit with Eclipse, you can tell it to specifically run all of the unit tests in a file. Or you can tell it to run only a single unit test. Or you can tell it to run them all. Right now, with D, you can only ever run them all, and you can't really integrate them into an IDE. I think that that should become possible at some point. Unfortunately, however, I don't know enough to say exactly how that would work. I don't even know how it works with JUnit and Eclipse. It is potentially a very important feature though.
 I do _not_ want to see D programs printing out anything more than they do
 when running unit tests. I'm totally open to external tools which do
 more (it would particularly good for IDEs to be able to run unittest
 blocks individually), but I do not want to see the basic framework
 change how it prints feedback on test successes and failures. It works
 great as it is now.

Yes, and if anyone wants more, a writefln("your message here") works just fine.

Yes. It is a bit of work to make all of your unit tests print success or failure, but it's not hard, just tedious. I see no reason to make everyone have to put up with extraneous output just because some people want it to print a list of successes and failures. If you really want that, you can do it yourself. The one part I can think of that you can't do yourself very well is print the total number of successes and failures (unless you print a running total with each test). But it's possible to build printing functionality on top of a framework that only prints out on failure, whereas it's not possible to get rid of printing with a framework that always prints. - Jonathan M Davis
Nov 26 2010