August 17, 2005
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
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
"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
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
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
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
"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
> 
> 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
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
"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