DSpec / Templates + Delegates

[Chris Mueller]

bearophile:
> I think that follows the type-II solution (the worst one) I have explained here:
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=107997
> (Thank you for your code and work, the worst solution is often better than no solution.)
>    

I enjoyed reading your article and i agree with you about the current 
Unittest-situation. If i remember my time working with other Unittesting 
Frameworks in other languages, i was always annoyed in the beginning to 
find out how to setup the tests and especially it's test execution. 
Often it was more comfortable to rely on some buildsystems, which 
already configured an automatic way. Though i doesn't like it to be 
depending on a specific buildsystem.

Walters approach to implement unittests into the compiler, is also in my 
opinion the most user-friendly way for developers to run unittest and 
avoids the annoying and time-consuming configuration management. (Though 
the D language give a great help to locate specific classes thanks to 
ModuleInfo struct and makes it eas implementing a testrunner in compare 
of other programming languages)

Thanks to the article i decided to move the dspec execution into the 
unittest environment (it's also already working now) in hope to make the 
configuration and test execution more simpler. I also agree that 
developers shouldn't waste much time in the setup and API of a 
unittesting framework, because it's only a tool for development.

Unfortanetly, i don't know a way to get commandline arguments which 
would offers to configure a unittest framework. I can indeed catch the 
arguments in the main function, but the unittest code is already 
executed before the main function will be invoked. A trivial workaround 
could be probably using a configuration file, which can be located and 
accessed by dspec framework.

Masahiro Nakagawa:
> I read sources. I have something on my chest.
>
> - ruun package
> Umm...need?
>    
It's surely not needed :) I already moved all modules to a simple dspec 
package.
> - import ruun.dspec.Spec; import ruun.dspec.Should;
> I think ruun.dspec.Spec should uses "public import" for Should module.
> Is there a case that spec empties in it! ?
>    
I know other unittest frameworks, that offers different implementation 
for assertions / expectations and the developer can chose one.
But setting Should.d to a public import would offer a standard 
implementation that is always accessible. Of course, this is a good idea.

> - Spec methods
> Why final? How can I create custom Spec?
>    
Is not needed anymore, because the Spec class is removed and the spec 
methods are moved to a single module now in order to get executed in a 
dmd unittest environment. (Though it won't also offer creating custom 
Specs).
Thank you very much for your code review.

If someone want to test dspec, be warned the buildscript (Rakefile) can 
maybe fail on Linux or Mac. I haven't test it yet on that
plattforms.

Jacob Carlborg:
> int[] array = [1, 2, 3, 4];
> int b = 10;
>
> array.each in (int item) {
> 	writefln("%d", item + b);
> };
>    
You are right :) I like it very much.

Chris Mueller

-- 

ruunhb at googlemail.com
http://ruuns.de/blog/