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:
# 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

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:
 # 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


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: # mFooSymbol; // ERROR. # mBarSymbol; // ERROR. # mBazSymbol; // ERROR. # # import mFoo; # mFooSymbol; // OK. # mBarSymbol; // ERROR. # mBazSymbol; // ERROR. # # class Bar { # mFooSymbol; // OK. # mBarSymbol; // ERROR. # mBazSymbol; // ERROR. # # import mBar; # mFooSymbol; // OK. # mBarSymbol; // OK. # mBazSymbol; // ERROR. # # void Baz() { # mFooSymbol; // OK. # mBarSymbol; // OK. # mBazSymbol; // ERROR. # # import mBaz; # mFooSymbol; // OK. # mBarSymbol; // OK. # mBazSymbol; // OK. # } # # mFooSymbol; // OK. # mBarSymbol; // OK. # mBazSymbol; // ERROR. # } # # mFooSymbol; // OK. # mBarSymbol; // ERROR. # mBazSymbol; // ERROR. 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: # mFooSymbol; // ERROR. # mBarSymbol; // ERROR. # mBazSymbol; // ERROR. # # import mFoo; # mFooSymbol; // OK. # mBarSymbol; // ERROR. # mBazSymbol; // ERROR.

This part so far is different than D today. mFooSymbol is available in the first line.
 # class Bar {
 #     mFooSymbol; // OK.
 #     mBarSymbol; // ERROR.
 #     mBazSymbol; // ERROR.
 #
 #     import mBar;
 #     mFooSymbol; // OK.
 #     mBarSymbol; // OK.
 #     mBazSymbol; // ERROR.

This is different, too.
 #     void Baz() {
 #          mFooSymbol; // OK.
 #          mBarSymbol; // OK.
 #          mBazSymbol; // ERROR.
 #
 #         import mBaz;
 #         mFooSymbol; // OK.
 #         mBarSymbol; // OK.
 #         mBazSymbol; // OK.
 #     }
 #
 #     mFooSymbol; // OK.
 #     mBarSymbol; // OK.
 #     mBazSymbol; // ERROR.
 # }
 #
 # mFooSymbol; // OK.
 # mBarSymbol; // ERROR.
 # mBazSymbol; // ERROR.

 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