Jump to page: 1 2
Thread overview
import statements inside unittests
Aug 17, 2005
Victor Nakoryakov
Aug 17, 2005
Niko Korhonen
Aug 17, 2005
Ben Hinkle
Aug 17, 2005
Niko Korhonen
Aug 17, 2005
Victor Nakoryakov
Aug 17, 2005
Ben Hinkle
Aug 17, 2005
Victor Nakoryakov
Aug 17, 2005
Derek Parnell
Aug 17, 2005
AJG
Aug 17, 2005
Ben Hinkle
Aug 17, 2005
Ant
Aug 17, 2005
Ben Hinkle
Aug 17, 2005
Derek Parnell
Aug 17, 2005
Ben Hinkle
Aug 17, 2005
AJG
Aug 17, 2005
Ben Hinkle
Aug 17, 2005
Ben Hinkle
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