View mode: basic / threaded / horizontal-split · Log in · Help
August 17, 2005
import statements inside unittests
Hi all.

Is there any reason for forbiding import statements inside unittests?
I often want import some module just for testing purposes only and do 
not want keep this dependency in release builds.

-- 
Victor (aka nail) Nakoryakov
nail-mail<at>mail<dot>ru

Krasnoznamensk, Moscow, Russia
August 17, 2005
Re: import statements inside unittests
Victor Nakoryakov wrote:
> Hi all.
> 
> Is there any reason for forbiding import statements inside unittests?
> I often want import some module just for testing purposes only and do 
> not want keep this dependency in release builds.
> 

I second this.

-- 
Niko Korhonen
SW Developer
August 17, 2005
Re: import statements inside unittests
"Victor Nakoryakov" <nail-mail@mail.ru> wrote in message 
news:ddv03k$2aug$1@digitaldaemon.com...
> Hi all.
>
> Is there any reason for forbiding import statements inside unittests?
> I often want import some module just for testing purposes only and do not 
> want keep this dependency in release builds.
>
> -- 
> Victor (aka nail) Nakoryakov
> nail-mail<at>mail<dot>ru
>
> Krasnoznamensk, Moscow, Russia

I agree writing code that only compiles in unittest builds would be nice. I 
think the compiler should define a version Unittest (or something like that) 
when unittests are enabled. That way you can have
 version(Unittest) {
   import foo;
   void func() {
     ... some helper function...
   }
   unittest {
     the tests...
   }
 }
and even add unittest-only code to classes being tested to get data or dump 
contents that wouldn't be built into release versions.
August 17, 2005
Re: import statements inside unittests
Ben Hinkle wrote:
> and even add unittest-only code to classes being tested to get data or dump 
> contents that wouldn't be built into release versions. 

A canonical example is printing some stuff in unit test in a module 
where cstream would not otherwise be needed:

<code>
import std.cstream; // only for unit test
unittest
{
  int x, y, z;
  // ..
  dout.writefln("Debug dump of some vars: ", x, y, z);
}
</code>

I could use printf in unit tests without importing std.cstream, but then 
I can't specify whether to write to dout or derr and I just like 
writefln too much :)

-- 
Niko Korhonen
SW Developer
August 17, 2005
Re: import statements inside unittests
On Wed, 17 Aug 2005 13:29:14 +0400, Victor Nakoryakov wrote:

> Hi all.
> 
> Is there any reason for forbiding import statements inside unittests?
> I often want import some module just for testing purposes only and do 
> not want keep this dependency in release builds.

Yes, that would just wonderful.

-- 
Derek Parnell
Melbourne, Australia
17/08/2005 11:02:19 PM
August 17, 2005
Re: import statements inside unittests
Ben Hinkle wrote:
> "Victor Nakoryakov" <nail-mail@mail.ru> wrote in message 
> news:ddv03k$2aug$1@digitaldaemon.com...
> 
>>Hi all.
>>
>>Is there any reason for forbiding import statements inside unittests?
>>I often want import some module just for testing purposes only and do not 
>>want keep this dependency in release builds.
>>
>>-- 
>>Victor (aka nail) Nakoryakov
>>nail-mail<at>mail<dot>ru
>>
>>Krasnoznamensk, Moscow, Russia
> 
> 
> I agree writing code that only compiles in unittest builds would be nice. I 
> think the compiler should define a version Unittest (or something like that) 
> when unittests are enabled. That way you can have
>   version(Unittest) {
>     import foo;
>     void func() {
>       ... some helper function...
>     }
>     unittest {
>       the tests...
>     }
>   }
> and even add unittest-only code to classes being tested to get data or dump 
> contents that wouldn't be built into release versions. 
> 
> 

Maybe version(Unittest) is even superfluous if you would able to write:

>     unittest {
>	import foo;
>     	void func() {
>       	... some helper function...
>     	}
>       the tests...
>     }

We already can define 'void func()' inside unittest, but 'import foo;' not.

-- 
Victor (aka nail) Nakoryakov
nail-mail<at>mail<dot>ru

Krasnoznamensk, Moscow, Russia
August 17, 2005
Re: import statements inside unittests
"Victor Nakoryakov" <nail-mail@mail.ru> wrote in message 
news:ddvhve$2tc2$1@digitaldaemon.com...
> Ben Hinkle wrote:
>> "Victor Nakoryakov" <nail-mail@mail.ru> wrote in message 
>> news:ddv03k$2aug$1@digitaldaemon.com...
>>
>>>Hi all.
>>>
>>>Is there any reason for forbiding import statements inside unittests?
>>>I often want import some module just for testing purposes only and do not 
>>>want keep this dependency in release builds.
>>>
>>>-- 
>>>Victor (aka nail) Nakoryakov
>>>nail-mail<at>mail<dot>ru
>>>
>>>Krasnoznamensk, Moscow, Russia
>>
>>
>> I agree writing code that only compiles in unittest builds would be nice. 
>> I think the compiler should define a version Unittest (or something like 
>> that) when unittests are enabled. That way you can have
>>   version(Unittest) {
>>     import foo;
>>     void func() {
>>       ... some helper function...
>>     }
>>     unittest {
>>       the tests...
>>     }
>>   }
>> and even add unittest-only code to classes being tested to get data or 
>> dump contents that wouldn't be built into release versions.
>
> Maybe version(Unittest) is even superfluous if you would able to write:
>
> >     unittest {
> > import foo;
> >     void func() {
> >       ... some helper function...
> >     }
> >       the tests...
> >     }
>
> We already can define 'void func()' inside unittest, but 'import foo;' 
> not.
>
> -- 
> Victor (aka nail) Nakoryakov
> nail-mail<at>mail<dot>ru
>
> Krasnoznamensk, Moscow, Russia

It would introduce a special case to parsing since import is not a 
statement. I'd rather not add a special case for parsing and instead add the 
more general Unittest version identifier and leverage the existing 
conditional compilation mechanisms. Importing a module only in certain 
builds is just what conditional compilation is good at doing.
August 17, 2005
Re: import statements inside unittests
> 
> It would introduce a special case to parsing since import is not a 
> statement. I'd rather not add a special case for parsing and instead add the 
> more general Unittest version identifier and leverage the existing 
> conditional compilation mechanisms. Importing a module only in certain 
> builds is just what conditional compilation is good at doing. 
> 

Hmm, it is too bulky:

version (Unittests)
{
	import std.string;
	unittest
	{
		...
	}
}

instead of:

unittest
{
	import std.string;
	...
}

I didn't search place in source where dmd parses unittests yet, but I 
don't think that adding this feature need much work.

-- 
Victor (aka nail) Nakoryakov
nail-mail<at>mail<dot>ru

Krasnoznamensk, Moscow, Russia
August 17, 2005
Re: import statements inside unittests
Hi,

What about arbitrarily nested import statements?

~Foo.d:
# import mFoo;
# 
# class Bar {
#     import mBar;
#
#     void Baz() {
#         import mBaz;
#     } 
# }

Seems more useful than a special case for unittest.
--AJG.


In article <ddv03k$2aug$1@digitaldaemon.com>, Victor Nakoryakov says...
>
>Hi all.
>
>Is there any reason for forbiding import statements inside unittests?
>I often want import some module just for testing purposes only and do 
>not want keep this dependency in release builds.
>
>-- 
>Victor (aka nail) Nakoryakov
>nail-mail<at>mail<dot>ru
>
>Krasnoznamensk, Moscow, Russia
August 17, 2005
Re: import statements inside unittests
"AJG" <AJG_member@pathlink.com> wrote in message 
news:ddvsig$4so$1@digitaldaemon.com...
> Hi,
>
> What about arbitrarily nested import statements?
>
> ~Foo.d:
> # import mFoo;
> #
> # class Bar {
> #     import mBar;
> #
> #     void Baz() {
> #         import mBaz;
> #     }
> # }
>
> Seems more useful than a special case for unittest.
> --AJG.

Yeah - I'm worried about what it actually means, though. Should the imported 
symbols only be visible after the executed statement or throughout the scope 
body? . Also given that imports inside classes and structs are discouraged 
(and undocumented I believe) by Walter I'd imagine that putting them inside 
functions will be even more hairy.

> In article <ddv03k$2aug$1@digitaldaemon.com>, Victor Nakoryakov says...
>>
>>Hi all.
>>
>>Is there any reason for forbiding import statements inside unittests?
>>I often want import some module just for testing purposes only and do
>>not want keep this dependency in release builds.
>>
>>-- 
>>Victor (aka nail) Nakoryakov
>>nail-mail<at>mail<dot>ru
>>
>>Krasnoznamensk, Moscow, Russia
>
>
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home