Extension Points in NUnit 2.5

Hi All,

Here's a list of extension points I think we will have for
the 2.5 release. It's far short of what I expect to put into
3.0, but a bit more than we have now. As you comment on this,
please keep in mind that 2.5 is intended to be an interim
release. :-)

CURRENT EXTENSION POINTS

SuiteBuilders - This will continue to work as it does now.

TestCaseBuilders - This will be modified to pass in the
TestFixture object, which is being populated. I worried
a little about breaking compatibility, but most extensions
currently need to be recompiled for new releases of NUnit
anyway. However, I could maintain the old interface as
well, if anyone sees a reason for it.

TestDecorators - I'd like to add a way that decorators
can state an ordering preference when they install themselves.

EventListeners - No change anticipated except for fixing the
bug that keeps it from working in the current release.

NEW EXTENSION POINTS (names are not final)

AssemblySuiteBuilder - To recognize attributes on assemblies
and build an appropriate test suite for it. This would do
for assemblies, what SuiteBuilder and TestCaseBuilder do
for types and methods.

  Optional: It may be reasonable to combine all three
  into one extension. They all take a reflection object
  and produce some sort of Test object. What do folks think?

TestDataProvider - A new extension point to encapsulate
a source of data to be used in instantiating a test. There
are some design issues around this, which Andreas is looking
into and will write about. It could end up being more than
one extension point - but we'll see. In the end, this could
be exploited by various data-provider syntaxes.

ProjectConverter - An extension point for addins that know
how to read some particular format and produce an NUnit
test project. I've already experimentally rewritten our
Visual Studio loading code to use this and it could be
used for other IDE formats as well as other test framework
project formats (csUnit recipe files, for example). There
are pros and cons to doing this in 2.5:

  Pro: This will give us a chance to experiment with our
  first extension point on the client side rather than in
  the test domain.

  Con: This could represent a bit of infrastructure work,
  which would need to be redone in 3.0.

  My Conclusion: See how much work it is.

GENERAL:

  I'd like to implement the feature whereby addins needed
  by a test are declared using an assembly attribute. If
  there is no declaration, things work just like now. If
  an addin is declared but is not installed, the entire 
  test fails.

  *********

Please let me know what you think of this as a plan - subject
to change as we go, of course.

Charlie



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/