digitalmars.D - unittext extension proposal

Jeremie Pelletier (22/22) Aug 08 2009 I just had an idea to help keep track of unittests, right now we're turn...

Sergey Gromov (6/12) Aug 10 2009 Named unittests is a rather often requested feature. Others also wanted

Leandro Lucarella (12/25) Aug 10 2009 It would be nice if unittest could be extended to have import statements...

Andrei Alexandrescu (4/19) Aug 10 2009 I use:

Jeremie Pelletier (3/26) Aug 10 2009 Thats the thing, I dont need every unittest compile to fill stdout with ...
Leandro Lucarella (12/34) Aug 10 2009 I know you can hack arround it, but it would be nice if the hack is not

Daniel Keep (3/9) Aug 11 2009 Another interesting problem is that because you can only mixin at module

Gide Nwawudu (5/27) Aug 12 2009 Something similar has been purposed.

Jeremie Pelletier <jeremiep gmail.com> writes:

I just had an idea to help keep track of unittests, right now we're turning on
printf's at the beginning of a test to know which one fails, and adding printfs
everywhere quickly becomes redundant. Also if the test succeeds and execution
fails at some other point, the last printf is then misleading.

---
module sample;
unittest("myTest") {}
---

With a few runtime changes, it could be made to print "unittest:
sample.myTest..." before calling the test routine, and "PASS\n" as the routine
returns. It could have its own compiler switch to turn it on or off globally,
and support for a custom output handler should the user want to redirect output
to a GUI or something.

Right now I made the following template to do that:
---
private template UnittestTrace(string test) {
	debug(TEST)
		immutable UnittestTrace =
			"printf(\"unittest: std.text.String." ~ test ~ "... \");"
			"scope(success) printf(\"PASS\n\");";
	else
		immutable UnittestTrace = "";
}
unittest {
    mixin(UnittestTrace!"myTest");
}
---

However being a dreamer and all, I would like to see support for such a feature
pushed to the D runtime.

J

Aug 08 2009

Sergey Gromov <snake.scaly gmail.com> writes:

Sat, 08 Aug 2009 17:32:30 -0400, Jeremie Pelletier wrote:

 I just had an idea to help keep track of unittests, right now we're turning on
printf's at the beginning of a test to know which one fails, and adding printfs
everywhere quickly becomes redundant. Also if the test succeeds and execution
fails at some other point, the last printf is then misleading.
 
 ---
 module sample;
 unittest("myTest") {}
 ---

Named unittests is a rather often requested feature.  Others also wanted
__UNITTEST__ to expand into a name of the current unittest.  Also a
'weak assert' was requested which tests and prints a message but delays
exit until the end of the current unit test.

Somebody should really write a DIP on this.

Aug 10 2009

Leandro Lucarella <llucax gmail.com> writes:

Sergey Gromov, el 10 de agosto a las 16:32 me escribiste:
 Sat, 08 Aug 2009 17:32:30 -0400, Jeremie Pelletier wrote:
 
 I just had an idea to help keep track of unittests, right now we're turning on
printf's at the beginning of a test to know which one fails, and adding printfs
everywhere quickly becomes redundant. Also if the test succeeds and execution
fails at some other point, the last printf is then misleading.
 
 ---
 module sample;
 unittest("myTest") {}
 ---

 
 Named unittests is a rather often requested feature.  Others also wanted
 __UNITTEST__ to expand into a name of the current unittest.  Also a
 'weak assert' was requested which tests and prints a message but delays
 exit until the end of the current unit test.

It would be nice if unittest could be extended to have import statements.

Even better, it would be nice to be able to use import statements in any
function or even any scope :)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Hey you, out there beyond the wall,
Breaking bottles in the hall,
Can you help me?

Aug 10 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Leandro Lucarella wrote:
 Sergey Gromov, el 10 de agosto a las 16:32 me escribiste:
 Sat, 08 Aug 2009 17:32:30 -0400, Jeremie Pelletier wrote:

 I just had an idea to help keep track of unittests, right now we're turning on
printf's at the beginning of a test to know which one fails, and adding printfs
everywhere quickly becomes redundant. Also if the test succeeds and execution
fails at some other point, the last printf is then misleading.

 ---
 module sample;
 unittest("myTest") {}
 ---

 Named unittests is a rather often requested feature.  Others also wanted
 __UNITTEST__ to expand into a name of the current unittest.  Also a
 'weak assert' was requested which tests and prints a message but delays
 exit until the end of the current unit test.

 
 It would be nice if unittest could be extended to have import statements.

I use:

version(unittest) import std.stdio;


Andrei

Aug 10 2009

Jeremie Pelletier <jeremiep gmail.com> writes:

Andrei Alexandrescu Wrote:

 Leandro Lucarella wrote:
 Sergey Gromov, el 10 de agosto a las 16:32 me escribiste:
 Sat, 08 Aug 2009 17:32:30 -0400, Jeremie Pelletier wrote:

 I just had an idea to help keep track of unittests, right now we're turning on
printf's at the beginning of a test to know which one fails, and adding printfs
everywhere quickly becomes redundant. Also if the test succeeds and execution
fails at some other point, the last printf is then misleading.

 ---
 module sample;
 unittest("myTest") {}
 ---

 Named unittests is a rather often requested feature.  Others also wanted
 __UNITTEST__ to expand into a name of the current unittest.  Also a
 'weak assert' was requested which tests and prints a message but delays
 exit until the end of the current unit test.

 
 It would be nice if unittest could be extended to have import statements.

 
 I use:
 
 version(unittest) import std.stdio;
 
 
 Andrei

Thats the thing, I dont need every unittest compile to fill stdout with
progress status. It's only needed when you have 300 unittests in a single
module and you cant tell which one is failing.

I for myself use an additional debug(TEST) check alongside with
version(unittest) for my test tracing features.

Aug 10 2009

Leandro Lucarella <llucax gmail.com> writes:

Andrei Alexandrescu, el 10 de agosto a las 10:15 me escribiste:
 Leandro Lucarella wrote:
Sergey Gromov, el 10 de agosto a las 16:32 me escribiste:
Sat, 08 Aug 2009 17:32:30 -0400, Jeremie Pelletier wrote:

I just had an idea to help keep track of unittests, right now we're turning 
on printf's at the beginning of a test to know which one fails, and adding 
printfs everywhere quickly becomes redundant. Also if the test succeeds and 
execution fails at some other point, the last printf is then misleading.

---
module sample;
unittest("myTest") {}
---

Named unittests is a rather often requested feature.  Others also wanted
__UNITTEST__ to expand into a name of the current unittest.  Also a
'weak assert' was requested which tests and prints a message but delays
exit until the end of the current unit test.

It would be nice if unittest could be extended to have import statements.

 
 I use:
 
 version(unittest) import std.stdio;

I know you can hack arround it, but it would be nice if the hack is not
needed. And being able to do import in any scope is nice in the sense that
you don't have to "pollute" al your file with an import (as bad as it is
that import x; imports all its symbols in the global scope =).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
CAYO HUGO CONZI  ---  TENIA PUESTA PELUCA
	-- Crónica TV

Aug 10 2009

Daniel Keep <daniel.keep.lists gmail.com> writes:

Leandro Lucarella wrote:
 ...
 
 I know you can hack arround it, but it would be nice if the hack is not
 needed. And being able to do import in any scope is nice in the sense that
 you don't have to "pollute" al your file with an import (as bad as it is
 that import x; imports all its symbols in the global scope =).

Another interesting problem is that because you can only mixin at module
level, string mixins designed to be used anywhere else cannot do imports.

Aug 11 2009

Gide Nwawudu <gide btinternet.com> writes:

On Sat, 08 Aug 2009 17:32:30 -0400, Jeremie Pelletier
<jeremiep gmail.com> wrote:

I just had an idea to help keep track of unittests, right now we're turning on
printf's at the beginning of a test to know which one fails, and adding printfs
everywhere quickly becomes redundant. Also if the test succeeds and execution
fails at some other point, the last printf is then misleading.

---
module sample;
unittest("myTest") {}
---

With a few runtime changes, it could be made to print "unittest:
sample.myTest..." before calling the test routine, and "PASS\n" as the routine
returns. It could have its own compiler switch to turn it on or off globally,
and support for a custom output handler should the user want to redirect output
to a GUI or something.

Right now I made the following template to do that:
---
private template UnittestTrace(string test) {
	debug(TEST)
		immutable UnittestTrace =
			"printf(\"unittest: std.text.String." ~ test ~ "... \");"
			"scope(success) printf(\"PASS\n\");";
	else
		immutable UnittestTrace = "";
}
unittest {
    mixin(UnittestTrace!"myTest");
}
---

However being a dreamer and all, I would like to see support for such a feature
pushed to the D runtime.

J

Something similar has been purposed.

http://d.puremagic.com/issues/show_bug.cgi?id=2749

Gide

Aug 12 2009

D Programming

C/C++ Programming

Other

digitalmars.D - unittext extension proposal