"Try it now"

[Jacob Carlborg]

On 2011-04-14 16:03, Steven Schveighoffer wrote:
> On Wed, 13 Apr 2011 21:04:25 -0400, Adam D. Ruppe
> <destructionator at gmail.com> 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