RE: Use of ExpectedExceptionAttribute class in unit tests

Hi Sunny,

> On 12/20/05, Charlie Poole <cpoole@xxxxxxxxxxxxxxxxxxx> wrote:
> > "Not welcome" is a pretty strong statement.
> 
> I did not mean to be offensive. Sorry if it sounds that way. Just then
> there were some post(s) supporting the idea, but as all we know, there
> were no time for this. Now, as the new version is out, I would like to
> offer my time again :)

I'm sure you didn't. And I wouldn't want to give the impression that your
ideas were unwanted.
 
> >
> > "Exceeded our bandwidth" is more accurate.
> 
> I do understand.

An added factor is our bias on this project toward doing something simple,
seeing if it solves the problems and going on from there. That can be
frustrating to someone who has a vision of an end solution already in mind.
I think the solution is to work out the frustration by coding. :-)

> >
> > One of the changes discussed in the past is in our 2.2.4 release.
> Additional
> > changes to ExpectedException are in the 2.4 release plan. Boris agreed
> to
> > work on making his particular idea an _extension_ rather than a change
> to
> > the NUnit core. Our focus on getting the extensibility mechanism working
> > right is aimed at exactly this problem: many people want many things out
> of
> > NUnit, and they can't all be in the core - or at least we don't think
> they
> > should be.
> >
> > Charlie
> 
> Extensions - as far as I understand - this is the way to create "new"
> test scenarios (attributes, etc.). Or adding functionality to the
> existing ones. 

Yes

> What am I missing. And is there any documentation where
> to start from? 

Extensibility.txt in the doc directory of the distribution is all there is -
plus some discussions that took place on this list. The txt file is out of
date as far as what's implemented and doesn't even mention some stuff I'm
working on now. That's because we're trying to implement the mechanism at
the same time as people are writing extensions and discovering new needs.

Boris' example came at just the right moment: I had an idea for improving
extensibility, but no example with which to drive it. Now I do.

[I'll be writing this up but here's the synopsis: We have mechanisms for
building custom fixtures and custom test cases but no mechanism for taking a
fixture or case - either builtin or custom - and adding one small bit of
behavior to it.]

> If I did not understand, and using these new mechanism
> changes can be made to existing scenarios, I'll be glad to work with
> Boris to prepare more broad extension than just COM exception
> checking.

Glad to have your help. That said, the ExpectedCOMException sounds very
expressive, which is an important user consideration. ExpectedException with
an HResult attribute might do it as well. An attribute that pointed to a
validation interface could be a bit harder to use. We have to balance
generality against ease of use.

> And, if I got it right, I still think that change in the base
> implementation of ExpectedException, which allows custom property test
> still holds water, as it can be a good base for additions, needed by
> Boris and others.

As we have implemented extensibility, we have re-implemented NUnit internals
as if they were extensions. So, for example, NUnitTestFixture is written as
if it were an extension - just one that's right in the core assembly. We
have a few attributes that can't be done that way, so they are hard-coded:
Ignore, ExpectedException, Category, Explicit, Platform. Note that these are
all attributes that need to apply to just about any test, even to a custom
test case that hasn't yet been invented.

If the direction I'm working on pans out, we would be able to implement this
sort of thing as an extension. Whether we would change the internals is
another matter, but we could.

I'm working on this on two fronts: code and docs. Since I'm a programmer,
you can guess which one I focus on and which I tend to postpone. At any
rate, I'll send you a copy of my draft doc at some point, and also post it
on the list. :-)

Charlie

> --
> --
> Svetoslav Milenov (Sunny)
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=ick
> _______________________________________________
> nunit-developer mailing list
> nunit-developer@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/nunit-developer




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click