Hi,

is there any well supported way to store the unittest code in different files then the actual code? I really don't like to clutter my code with tests or test helper functions.

Also: Is there a library or possibility to turn the "example:" ddoc sections into unittests?

Greetings, Tobias

On Tue, 06 Sep 2011 12:42:08 -0400, Tobias Pankrath <tobias@pankrath.net> wrote:

> Hi,
>
> is there any well supported way to store the unittest code in different
> files then the actual code? I really don't like to clutter my code with
> tests or test helper functions.

Yes, just move those unit tests into another module.

However, it won't have access to private members.

>
> Also: Is there a library or possibility to turn the "example:" ddoc
> sections into unittests?

That is a oft-requested feature, and I think eventually it will make its way into D.

I don't think there's any library that does it currently.

-Steve

> 
> Yes, just move those unit tests into another module.
> 
> However, it won't have access to private members.

Which is IMO a showstopper.

How do you handle your unit tests? I am now stuffing everything related to unit tests at the bottom of the module into an private scope (section?). This way it is out of the way and I can easily "fold" it with my editor.

Tobias Pankrath:

> is there any well supported way to store the unittest code in different files then the actual code? I really don't like to clutter my code with tests or test helper functions.

Unittests too are code. I suggest to keep unittests close to the code they test because this is handy (unless there are a large amount of tests).
D has nestable functions, so you are often able to put the helper functions inside the unittests.

Bye,
bearophile

If you really need that you could use the import expression to mixin your unittests.
But you should really put the unittests next to the tested code. A good editor could fold it anyway.

On 2011-09-06 19:15, Tobias Pankrath wrote:
>>
>> Yes, just move those unit tests into another module.
>>
>> However, it won't have access to private members.
>
> Which is IMO a showstopper.
>
> How do you handle your unit tests? I am now stuffing everything related
> to unit tests at the bottom of the module into an private scope
> (section?). This way it is out of the way and I can easily "fold" it
> with my editor.

I have my unit tests in a completely different package: https://github.com/jacob-carlborg/orange/tree/master/tests

-- 
/Jacob Carlborg