Thread overview | |||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Victor Nakoryakov | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Victor Nakoryakov | "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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Victor Nakoryakov | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Victor Nakoryakov | "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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | > > 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Victor Nakoryakov | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to AJG | "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 > > |
Copyright © 1999-2021 by the D Language Foundation