• Tobias Pankrath (7/7) Sep 06 2011 Hi,
• Steven Schveighoffer (8/14) Sep 06 2011 Yes, just move those unit tests into another module.
• Tobias Pankrath (5/9) Sep 06 2011 Which is IMO a showstopper.
• Jacob Carlborg (5/14) Sep 06 2011 I have my unit tests in a completely different package:
• bearophile (5/8) Sep 06 2011 Unittests too are code. I suggest to keep unittests close to the code th...
• bearophile (12/15) Sep 06 2011 I think the normal way to lay D unittests is:
• Trass3r (4/4) Sep 06 2011 If you really need that you could use the import expression to mixin you...

Tobias Pankrath <tobias pankrath.net> writes:

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

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

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

Tobias Pankrath <tobias pankrath.net> writes:

 
 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.

Jacob Carlborg <doob me.com> writes:

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

bearophile <bearophileHUGS lycos.com> writes:

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

bearophile <bearophileHUGS lycos.com> writes:

Tobias Pankrath:

 Which is IMO a showstopper.

Because in D unittests are meant to be put beside the code they test. If you go
against the language, you sometimes find troubles :-)

 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

I think the normal way to lay D unittests is:

function A
unittest of A
function B
unittest of B
Class C
unittest of C
...

Bye,
bearophile

Trass3r <un known.com> writes:

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.