[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