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.

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

-----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-----

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

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/

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

- progress report (" ##%: testing case X of Y")

- 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

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.

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

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

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