std.unittests for (final?) review

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Jan 3 07:17:56 PST 2011


On 1/3/11 9:02 AM, Jonathan M Davis wrote:
> On Monday 03 January 2011 06:43:24 Andrei Alexandrescu wrote:
>> On 1/3/11 3:38 AM, Vladimir Panteleev wrote:
>>> On Mon, 03 Jan 2011 06:44:50 +0200, Jonathan M Davis
>>>
>>> <jmdavisProg at gmx.com>  wrote:
>>>> So, please have a look at the code.
>>>
>>> Just one thing: wouldn't these functions also be useful in contract
>>> programming (invariants etc.)? Perhaps they should just be added to
>>> std.exception?
>>
>> In fact (without looking at std.unittest) I think it should be grouped
>> with a simple benchmark facility. That's what the homonym frameworks in
>> Google's and Facebook's code base do.
>
> I'm afraid that I don't see what unit test helper functions have to do with
> benchmarking.

They both help the decision: "Is this module good to go?" At work we 
almost always put benchmarks in the same file as the unit tests, and run 
them together (subject to a --benchmark flag because benchmarks tend to 
take a fair amount of time). I find that very natural, although I should 
add that the unittest and benchmark libraries are nominally distinct.

> And I don't believe that we have a benchmarking module at the
> moment regardless, so if you want to do that, we'd need to create one. The only
> benchmarking stuff that I'm aware of is the bencharking stuff in std.datetime that
> SHOO did, which isn't all that much code. I would have thought that unit test
> helper functions would merit their own module, particularly when I don't see
> what they have to do with benchmarks.

Adding basic support for benchmarking shouldn't be difficult and does 
not entail a lot of code, but I understand it if you're not all that 
motivated to work on that.


Andrei


More information about the Digitalmars-d mailing list