On 2011-04-14 16:03, Steven Schveighoffer wrote:
On Wed, 13 Apr 2011 21:04:25 -0400, Adam D. Ruppe
<[email protected]> wrote:
On the other hand, having output there might be more interesting
to look at than "yay the asserts all passed!".
I think this is a good point. Someone playing with a language might type
in the example, and do:
/home/steves> dmd example.d
/home/steves> ./example
/home/steves> (ok... I guess that worked, but I'm not sure what happened)
In other words, there is a benefit to the interaction with the learner.
In other words, you get to "see it working", rather than only see when
it fails. You also get a confirmation that the compiler is actually
building something. For the above code, all one really knows is that the
compiler made an executable. There's no confirmation that the code being
run is actually what you typed in.
Sometimes, I worry that my unit tests or asserts aren't running. Every
once in a while, I have to change one to fail to make sure that code is
compiling (this is especially true when I'm doing version statements or
templates). It would be nice if there was a -assertprint mode which
showed asserts actually running (only for the module compiled with that
switch, of course).
-Steve
I agree. For one of my projects I created a simple unit test "framework"
that:
* Displays the number of tests
* Doesn't stop the whole run when a single assert fails
* Prints out the failing asserts, if any
* It's possible to add descriptions to the tests
The testing framework in use:
http://www.dsource.org/projects/orange/browser/tests/Serializer.d#L249
The actual framework:
http://www.dsource.org/projects/orange/browser/orange/test/UnitTester.d
--
/Jacob Carlborg
