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

[Andrey Khropov]

Kamil Dworakowski wrote:

> Andrey Khropov wrote:
> > To fully explore all the features present in NUnit we need to support other
> > notions present in NUnit in form of attributes:
> >  
> That was never my intention to support all the features of NUnit. My aim was
> to make a DSL to write readable tests. I will object to any change that would
> compromise that goal.

I don't want to compromise this goal. But I think as far as NemerleUnit is
NUnit-based it is natural for a user to expect that all of the NUnit features
are supported.

I just want to add some non-breaking functionality, if you don't need it -
don't use it.

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.

> 
> I think that with NemerleUnit in  its current state I can implement 95% unit
> tests I want. For the remaining 5% I would use NUnit directly. For instance,
> Template Pattern for tests where you create an abstract TestFixture class and
> concrete TestFixture subclasses (sometimes done to test interfaces or
> abstract classes).

Yes, sometimes we have to expose all the details. But just replacing

[TestFixture] module MyFixture
{ ... }

with

testfixture MyFixture

and

[SetUp] SetUp() : void {  }

with

setup { }

makes code clearer and better express its semantics (void and () in this
example are of course redundant)

> 
> > 1) TestFixture
> > AFAIKS the current implementation implicitly adds this attribute to the
> > current    enclosing type when test macro is executed. Maybe it's Ok or
> > maybe there should be a testfixture macro (for consistency with test macro
> > style):
> > 
> > 
> > testfixture MyFixture // translated to [TestFixture] module MyFixture
> > {
> > 	...
> > }
> >  
> 
> 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
            }
        ]> );
        <[]>
-------------------------------------------------------------------------------

? (I'm not a macro expert)

> Currently there is a fixture made automatically for your
> testing pleasure.

I noticed that

> 
> > 2) TestFixtureSetup, TestFixtureTearDown.
> >  
> They would not be easy to add 

why? Just create functions with these attributes as it the other cases.

> and are rarely needed at the same time.

may be you're right

> > 3) ExpectedException, Platform, Category, Explicit, Ignore
> > 
> >   These cases are more complicated. Can we add attributes like always:
> > 
> > 	[ExpectedException(typeof(InvalidOperationException))]
> > 	test MyTest
> > 	{
> > 
> > 	}
> > 
> > 	?
> >  
> These should be easy to add. I would do sth like
> 
> expect_exception exception_type "decription for the test"
> {
> }

Hmm, I think that it should be clear to the reader that this is *a test* that
expects an exception to be thrown, not *something* that is expected to throw an
exception.

> 
> ignore_test "name"
> {
> }

Maybe that's ok, or may be using attribute would be more consistent (and of
course we can have ExpectException and Ignore at the same time)

-- 
AKhropov