www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dmd unittest

reply Hiroshi Sakurai <Hiroshi_member pathlink.com> writes:
This topic was written by Crara in D language wiki of Japan. 
------
http://f17.aaa.livedoor.jp/~labamba/?BugTrack%2F11
I hope that dmd improve the usability of unittest. 
I don't want to write the main function at the unittest option.

example now
------
t.d
unittest {printf("t\n");}
void main(){}


dmd t1.d -unittest
t1


t
------
example Crara idea
------
t.d
unittest {printf("t\n");}


dmd t1.d -unittest
t1


t
------

thanks
Hiroshi Sakurai.
Mar 17 2005
next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Hiroshi Sakurai <Hiroshi_member pathlink.com> wrote:

[...]

 I don't want to write the main function at the unittest option.


[...]

I support this, because one is forced to introduce a `main' for the 
unittest at module level. Once introduced the exixtence of the 
`main' is forgotten and when it comes to the integration test all 
modules have to be reedited.

-manfred
Mar 17 2005
parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Manfred Nowak schrieb am Thu, 17 Mar 2005 12:05:06 +0000 (UTC):

 Hiroshi Sakurai <Hiroshi_member pathlink.com> wrote:

 [...]

 I don't want to write the main function at the unittest option.


 [...]

 I support this, because one is forced to introduce a `main' for the 
 unittest at module level. Once introduced the exixtence of the 
 `main' is forgotten and when it comes to the integration test all 
 modules have to be reedited.


How would you add this feature to the compiler?
- -> projects with more than one source/object file...

The linking could be changed to add a generic main if none of
the provided object files containted a main....

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCOXZg3w+/yD4P9tIRAgqSAJ0T1sEvPSbOT8lt0PZeW1gxKqj84gCdF4iw
5I84Iq+Ujjqs/+Gvws3XyIg=
=nk/j
-----END PGP SIGNATURE-----
Mar 17 2005
next sibling parent "Alex Stevenson" <ans104 cs.york.ac.uk> writes:
On Thu, 17 Mar 2005 13:21:53 +0100, Thomas Kuehne  
<thomas-dloop kuehne.thisisspam.cn> wrote:


 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Manfred Nowak schrieb am Thu, 17 Mar 2005 12:05:06 +0000 (UTC):

 Hiroshi Sakurai <Hiroshi_member pathlink.com> wrote:

 [...]

 I don't want to write the main function at the unittest option.


 [...]

 I support this, because one is forced to introduce a `main' for the
 unittest at module level. Once introduced the exixtence of the
 `main' is forgotten and when it comes to the integration test all
 modules have to be reedited.


 How would you add this feature to the compiler?
 - -> projects with more than one source/object file...

 The linking could be changed to add a generic main if none of
 the provided object files containted a main....

 Thomas


 -----BEGIN PGP SIGNATURE-----

 iD8DBQFCOXZg3w+/yD4P9tIRAgqSAJ0T1sEvPSbOT8lt0PZeW1gxKqj84gCdF4iw
 5I84Iq+Ujjqs/+Gvws3XyIg=
 =nk/j
 -----END PGP SIGNATURE-----


How about the -unittest option creating two executables? prog.exe and  
prog-unittest.exe. AFACS this would just be a case of running the linker  
twice over the objects, linking with a dummy unittest main for the  
unittest pass (Similar to the GC stub object for DLLs?). This would  
seperate out the unit tests, making them easier to use as an acceptance  
test for a build and remove the need to compile a large project twice just  
to get unittests.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Mar 17 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Thomas Kuehne wrote:


 How would you add this feature to the compiler?
 - -> projects with more than one source/object file...
 
 The linking could be changed to add a generic main if none of
 the provided object files containted a main....


But this could be taken SO much further than
just adding a missing one-line stub for main...


In *other* languages with unit testing, such as
Perl or Java for instance, there are features like:

- friendly user interfaces for running the tests
   (http://search.cpan.org/dist/Test-Simple/lib/Test/Tutorial.pod
    http://cppunit.sourceforge.net/cgi-bin/moin.cgi/MfcTestRunner)

- continuing test, after first assertion fails



- test description (now testing: "is_perfect_001")

- progress summary (PASS: X, FAIL: Y, SKIP: Z)

- progress running time and cpu resources used

+ and so on, and so forth...


There are plenty of such improvements to be made in D....
Just hope that having unittest built-in won't stop those ?

--anders
Mar 17 2005
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Hiroshi Sakurai wrote:


 I hope that dmd improve the usability of unittest. 
 I don't want to write the main function at the unittest option.
 
 example now
 ------
 t.d
 unittest {printf("t\n");}
 void main(){}


This example does *not* work with current versions of DMD...
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3073

Currently one *must* use the form "int main() { return 0; }"
for all unittests, since "void main" returns random values.


A simple workaround at the moment is to use a version(***),
to compile the "main" program for a certain module unittest.

Or you can do like Java (JUnit) and place the unit testing
code in a separate module, for blackbox testing of another ?


The annoying part is to make sure that all the modules to be
tested are actually referenced by the unittest main program.

See the Phobos unittest.d for how ugly this can get... ;-)

--anders
Mar 17 2005
parent reply Ben Hinkle <Ben_member pathlink.com> writes:
In article <d1bt9e$qao$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

Hiroshi Sakurai wrote:


 I hope that dmd improve the usability of unittest. 
 I don't want to write the main function at the unittest option.
 
 example now
 ------
 t.d
 unittest {printf("t\n");}
 void main(){}


This example does *not* work with current versions of DMD...
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3073

Currently one *must* use the form "int main() { return 0; }"
for all unittests, since "void main" returns random values.


The issue of void main is completely separate from unittesting. I think it is
misleading to say one must use the int main form.

[snip]

The annoying part is to make sure that all the modules to be
tested are actually referenced by the unittest main program.


agreed - this part is annoying.
Mar 17 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:


Currently one *must* use the form "int main() { return 0; }"
for all unittests, since "void main" returns random values.


 
 The issue of void main is completely separate from unittesting.
 I think it is misleading to say one must use the int main form.


If you don't, the unit test will fail... (at least for me, on Unix)
I just hope the bug will be fixed, and we can forget all about it ?
Tried to fix it myself meanwhile, but I haven't succeeded (yet)...

char[] main() { return "OK"; } // returns 2
ireal main() { return 1.0i; } // returns 3
void main() {} // returns 4

Not even my patch for checking the return type of main has been added.
i.e. "function test.main return type must be either void or int"
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2853

Sorry if I sound grumpy. Just that the development is going slooow ?
--anders
Mar 17 2005
parent reply Ben Hinkle <Ben_member pathlink.com> writes:
In article <d1c0k2$sba$2 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

Ben Hinkle wrote:


Currently one *must* use the form "int main() { return 0; }"
for all unittests, since "void main" returns random values.


 
 The issue of void main is completely separate from unittesting.
 I think it is misleading to say one must use the int main form.


If you don't, the unit test will fail... (at least for me, on Unix)


The unit test passes (well, it just prints something). The program that runs the
unittests returns a random value to the shell. That's the way the OP wrote the
program and there's nothing wrong with what they wrote IMO. I use the int main
form but that's just habit. If one writes a test harness that depends on the
return value then naturally one would have to use int main.


I just hope the bug will be fixed, and we can forget all about it ?


I don't think you've convinced Walter it's a bug (at least I don't recall him
voicing that). I'm comfortable with the current behavior unless there are
systems that become unstable with void main programs.


Tried to fix it myself meanwhile, but I haven't succeeded (yet)...

char[] main() { return "OK"; } // returns 2
ireal main() { return 1.0i; } // returns 3
void main() {} // returns 4

Not even my patch for checking the return type of main has been added.
i.e. "function test.main return type must be either void or int"
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2853

Sorry if I sound grumpy. Just that the development is going slooow ?


no problem


--anders
Mar 17 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:


 The unit test passes (well, it just prints something).


When doing makefiles and scripts, and automated testing
in general, it is important to check program return values.

Unless this printout can be automatically tested, then it's
not good for doing automatic testing - and that's important.


 The program that runs the
 unittests returns a random value to the shell.


Since this random value (well, "EAX register") is always
different from zero, the program fails - *by definition*.

Inserting "exit(0);" would also work, but is less elegant...
(but exit would work for making "void main()" programs fail)


 That's the way the OP wrote the
 program and there's nothing wrong with what they wrote IMO.


Nope, the problem is with the D program language specification
and with implementation of the reference compiler. If it allows
"void main" (ANSI C doesn't), then that *should* return 0 back...

I believe C++ even inserts a "return 0;" into "int main()" too ?
(in D, it would probably be better to have that case be an error,
as discussed a lot in the other thread about "missing return")

Anything would be an improvement over the current D mess. :-P


 I don't think you've convinced Walter it's a bug (at least I don't recall him
 voicing that). I'm comfortable with the current behavior unless there are
 systems that become unstable with void main programs.


It's a big concern with D. Especially that it is taking so long?
Like the implicit "printf" definition. Simple now, hard later...

My own suspiscion is that the Windows console is so broken anyway,
that nobody bothers to even check for exit values? ("errorlevel")

--anders
Mar 17 2005