Sealed on attribute classes.

[Martin Mazur]

Hello,

we just started a project, NUSpec [1], that is attempting to build a
BDD framework which is compatible with NUnit. We where thinking of
using NUnitLite and build a layer ontop of it that adds BDD style
assertions and some other syntactic suger.

However since the attributes in NUnitLite are sealed we can't extend
them to add what we need.

I was just wondering what the reason for this and if, maybe, it could
be changed.
If this isn't possible we understand and we can always move to full
NUnit that dosen't have the attributes sealed.

//M

[1] http://wiki.github.com/mazur/nuspec

[Charlie Poole]

Hi Martin,

Attributes are sealed in NUnitLite for several reasons...

1) Most .NET BCL attributes are sealed.

2) NUnit attributes *were* sealed at the time NUnitLite
was created.

3) Allowing inheritance would probably lead folks to
imagine that the derived attributes should work in
marking tests, etc. but they would not - or at least
did not in the past.

More recently, NUnit was modified to allow most attributes
to be inherited from *and* to actually work. So, in NUnit,
if you derive SpecAttribute from TestAttribute, it will
actually work. In the current state of NUnitLite, the results
would be mixed, depending on the Attribute, but eventually
they will be unsealed and actually made to work.

Unless you have a reason to need a very small footprint for
your application, I'd suggest basing it on NUnit 2.5. Currently,
it has features that have not yet made it into NUnitLite,
although they will be migrated there later this year.
Eventually, the two frameworks will be based on the same
source code with some conditional compilation.

Looking at your blog post, I'd say that most of what you
want to do is easy enough to do using NUnit. If you
aren't familiar with the Constraint model in NUnit 2.4
and (especially) 2.5, I suggest taking a look at it.
You may be able to build everything on top of the
pre-existing constraints in NUnit.

If you'd care to describe any other kinds of things you want
to layer on top of NUnit, I'd be glad to make more detailled
suggestions.

Also, on the nunit-discuss list, two guys are currently
debating alternate syntaxes for their own extensions
layered on top of NUnit. Their goals are different from
yours, but some of the techniques would apply equally.

Charlie

[Martin Mazur]

Hello,

Thanks for the awnser Charlie.

> More recently, NUnit was modified to allow most attributes
> to be inherited from *and* to actually work. So, in NUnit,
> if you derive SpecAttribute from TestAttribute, it will
> actually work. In the current state of NUnitLite, the results
> would be mixed, depending on the Attribute, but eventually
> they will be unsealed and actually made to work.

Ah, I see. I've tried this with NUnit 2.4.8 and it worked fine so I
just assumed it would work with NUnitLite. If the results are
unpredictable then of course the attributes should be sealed to avoid
missunderstanding.

> Unless you have a reason to need a very small footprint for
> your application, I'd suggest basing it on NUnit 2.5.

The only reason we wanted to try NUnitLite instead of standard NUnit
is because we only need a subpart of the framwork. With NUnitLite we
basically got the part of the framework we where intressted in and
nothing else.

> Looking at your blog post, I'd say that most of what you
> want to do is easy enough to do using NUnit. If you
> aren't familiar with the Constraint model in NUnit 2.4
> and (especially) 2.5, I suggest taking a look at it.
> You may be able to build everything on top of the
> pre-existing constraints in NUnit.

Yes, I am familiar with the constraint based model and I like it very
much. We may very well end up build ontop of that. However there are a
few thing we want to do that might not be possible if we build ontop
of the existing model. I will invetigate this further.

> If you'd care to describe any other kinds of things you want
> to layer on top of NUnit, I'd be glad to make more detailled
> suggestions.

Really what we want to do is very simple. Except for aliasing the
attributes we want to add two extension methods to object:

Should(Constraint x)
ShouldNot(Constraint x)

Then we want to add Constraints in a similar way as the NUnit
Constraint based assertion model.

Be.EqualTo(x)
Be.LessThan(x)

and so forth...

These are the basics. Once we reach this point we will start adding
more syntax suggering like the abbility to add assertion messages to
constraints using a Because method:

var x = new Cat();
x.Should(Be.EqualTo(x).Because("they are the same cat"));

> Also, on the nunit-discuss list, two guys are currently
> debating alternate syntaxes for their own extensions
> layered on top of NUnit. Their goals are different from
> yours, but some of the techniques would apply equally.

Thanks for pointing this out. I've joined the NUnit group and I'll be
reading up on Fabio's NUnitEx and Simone's LinUnit.

Thanks again for your awnser.

//M

[Charlie Poole]

Hi Martin,

> Ah, I see. I've tried this with NUnit 2.4.8 and it worked
> fine so I just assumed it would work with NUnitLite. If the
> results are unpredictable then of course the attributes
> should be sealed to avoid missunderstanding.

Actually, now that I think of it, it *would* work with NUnitLite
provided you used NUnit as the runner rather than using the
built-in NUnitLite runner. Since NUnitLite is intended to be
used at the source level, you may want to try unsealing the
attributes and giving it a shot. Just load your tests into
the NUnit runner and see what happens. :-)

> Really what we want to do is very simple. Except for aliasing
> the attributes we want to add two extension methods to object:
>
> Should(Constraint x)
> ShouldNot(Constraint x)

NUnit won't support an approach like this right away, but it's
coming. The ey issue

> Then we want to add Constraints in a similar way as the NUnit
> Constraint based assertion model.
>
> Be.EqualTo(x)
> Be.LessThan(x)
>
> and so forth...
>
> These are the basics. Once we reach this point we will start
> adding more syntax suggering like the abbility to add
> assertion messages to constraints using a Because method:
>
> var x = new Cat();
> x.Should(Be.EqualTo(x).Because("they are the same cat"));

Interesting...

> > Also, on the nunit-discuss list, two guys are currently debating
> > alternate syntaxes for their own extensions layered on top
> of NUnit.
> > Their goals are different from yours, but some of the
> techniques would
> > apply equally.
>
> Thanks for pointing this out. I've joined the NUnit group and
> I'll be reading up on Fabio's NUnitEx and Simone's LinUnit.

See you there!

Charlie