[nem-en] [NemerleUnit] What about other attributes availablein NUnit?

Kamil Dworakowski kamil.dworakowski at googlemail.com
Mon Feb 5 10:55:27 CET 2007


Andrey Khropov wrote:
> I just want to add some non-breaking functionality, if you don't need it -
> don't use it.
>   
Sure, go ahead.
> I can of course make my own package (it's not that hard) but I think one
> standard approach for all Nemerle users would be better.
>   
Definitely.
>> That would allow for having two test fixtures in one file, but it's probably
>> hard to implement. 
>>     
>
> Is anything wrong with that:
>
> -------------------------------------------------------------------------------
>  macro testfixture(name, class_body) syntax ("testfixture", name, class_body ) 
>         Nemerle.Macros.ImplicitCTX ().Env.Define( <[ 
>             decl: [TestFixture] public module $(name.ToString().Replace("\"",
> "") : dyn)(){
>                 ..$class_body
>             }
>         ]> );
>         <[]>
> -------------------------------------------------------------------------------
>
> ? 
>   
Here you go, that could work!
>>> 2) TestFixtureSetup, TestFixtureTearDown.
>>>  
>>>       
>> They would not be easy to add 
>>     
>
> why? Just create functions with these attributes as it the other cases.
>   
Unfortunately, there is a problem. Body of setup is pasted into each 
generated test method. There is no [SetUp] method created. That, 
obviously, does not extend to fixture types of setup and teardown.

The only alternative I could think of was to add two new keywords for 
defining variables and methods accessible from every other method in the 
class; e.g. helper_function, variable, and then put setup body to 
[SetUp] method.

helper_function example(num: int): string // makes private method
     $"$prefix $num"

variable prefix: string // makes field

That solution, however less wasteful, would impose giving types for 
helper functions and variables, so I decided that the former approach 
was better (less code to write and read). The biggest disadvantage of 
current implementation is that setup is copied as many times over as 
there are tests. What do you think about this?

Kamil Dworakowski



More information about the devel-en mailing list