www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - import statements inside unittests

reply Victor Nakoryakov <nail-mail mail.ru> writes:
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
Aug 17 2005
next sibling parent Niko Korhonen <niktheblak hotmail.com> writes:
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
Aug 17 2005
prev sibling next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"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.
Aug 17 2005
next sibling parent Niko Korhonen <niktheblak hotmail.com> writes:
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
Aug 17 2005
prev sibling parent reply Victor Nakoryakov <nail-mail mail.ru> writes:
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
Aug 17 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"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.
Aug 17 2005
parent Victor Nakoryakov <nail-mail mail.ru> writes:
 
 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
Aug 17 2005
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
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
Aug 17 2005
prev sibling next sibling parent reply AJG <AJG_member pathlink.com> writes:
Hi,

What about arbitrarily nested import statements?

~Foo.d:










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
Aug 17 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"AJG" <AJG_member pathlink.com> wrote in message 
news:ddvsig$4so$1 digitaldaemon.com...

 Hi,

 What about arbitrarily nested import statements?

 ~Foo.d:










 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
Aug 17 2005
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <de04ab$b14$1 digitaldaemon.com>, Ben Hinkle says...

 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


Why do you say that?

"The top level scope in the module is merged with the current scope."
from http://www.digitalmars.com//d/index.html

I see no limitation on "current scope", but I remember a compiler message
about the scope of the import declaration.

Ant
Aug 17 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Ant" <Ant_member pathlink.com> wrote in message 
news:de050d$blb$1 digitaldaemon.com...

 In article <de04ab$b14$1 digitaldaemon.com>, Ben Hinkle says...

 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


 Why do you say that?

 "The top level scope in the module is merged with the current scope."
 from http://www.digitalmars.com//d/index.html

 I see no limitation on "current scope", but I remember a compiler message
 about the scope of the import declaration.

 Ant


That sentance appears in the 'module' page. No mention of importing other 
than at the top level of a module is made in the D docs (from what I could 
tell). The production DeclDefs in module.html is the only place I could find 
imports explicitly listed in the "grammar" such as it is. For example the 
next section "Scope and Modules" only talks about importing a module into 
another module. The classes.html doc doesn't talk about importing or what it 
means (in general the classes.html never seems to actually say what's 
allowed inside a class body). If one interprets "current scope" as really 
meaning any scope then it would also include function scopes - which 
currently doesn't work. So I think attaching too much meaning to the words 
"current scope" is dangerous - the web pages are .. umm... informal.

I also briefly tried searching for a post I recall where he suggested people 
avoid importing inside class bodies even though it technically works 
(depending on bugs, I think). None of the threads with the obvious subject 
names had anything useful and it's impossible to search those long 
meandering threads with generic subjects. I know several people argued 
strongly that they try to import inside classes as much as possible so it's 
a touchy subject.
Aug 17 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 17 Aug 2005 16:47:54 -0400, Ben Hinkle wrote:


[snip]
 

 No mention of importing other than at the top level of a module is made in
 the D docs (from what I could tell). The production DeclDefs in module.html
 is the only place I could find imports explicitly listed in the "grammar"
 such as it is ...


Backing up a little ... it would be useful if Walter could provide an
easy-to-use mechanism so that specific imports only occurred during unit
testing.

-- 
Derek Parnell
Melbourne, Australia
18/08/2005 6:56:15 AM
Aug 17 2005
parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:1jg0ds14poumr.gmvd6saz5sez$.dlg 40tude.net...

 On Wed, 17 Aug 2005 16:47:54 -0400, Ben Hinkle wrote:


 [snip]


 No mention of importing other than at the top level of a module is made 
 in
 the D docs (from what I could tell). The production DeclDefs in 
 module.html
 is the only place I could find imports explicitly listed in the "grammar"
 such as it is ...


 Backing up a little ... it would be useful if Walter could provide an
 easy-to-use mechanism so that specific imports only occurred during unit
 testing.

 -- 
 Derek Parnell
 Melbourne, Australia
 18/08/2005 6:56:15 AM


ok - that's the point of this thread. Was there some confusion I missed? AJG 
was generalizing the original proposal.
Aug 17 2005
prev sibling parent reply AJG <AJG_member pathlink.com> writes:
Hi,


 Hi,
 What about arbitrarily nested import statements?
 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? . 


I'm not saying I know "the" answer to this one, nor is this a feature I'm
desperate about, but to me it would mean something like the following:

~Foo.d:







































Don't know if I missed any cases in there.


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.


Do you mean semantically or in terms of the compiler's own implementation?

Cheers,
--AJG.
Aug 17 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"AJG" <AJG_member pathlink.com> wrote in message 
news:de069s$cpb$1 digitaldaemon.com...

 Hi,


 Hi,
 What about arbitrarily nested import statements?
 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? .


 I'm not saying I know "the" answer to this one, nor is this a feature I'm
 desperate about, but to me it would mean something like the following:

 ~Foo.d:










This part so far is different than D today. mFooSymbol is available in the 
first line.













This is different, too.






















 Don't know if I missed any cases in there.


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.


 Do you mean semantically or in terms of the compiler's own implementation?

 Cheers,
 --AJG.


Personally if putting restrictions on the places where imports are allowed 
helps make compilers simpler and less buggy (eg Java forces all imports at 
the top) then I'm all for it. The current documentation on imports is very 
vague.
Aug 17 2005
prev sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"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


Actually now that I think about it why is "private import" inadequate? A 
private import should have no effect on modules that import the original 
module.
Aug 17 2005