Re: Extension Points in NUnit 2.5

>  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.

This sounds really useful to me. I can think of all sorts of tests
that could be run on an assembly basis using metadata.. and this would
really help in building those sorts of tests automatically.

>   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?

I don't have a strong opinion on this... would it change the way
current things work? What are the trade offs, pro and con for putting
them all together? Would it help in creating new variants?

>  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.

Can we please have this discussion out on the list...

>  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.

If you looked at it as a prototype for 3.0, and thought about what we
might learn about the problem domain, that might tip the decision
point to some extent.

In general, this extension point sounds like it might be very useful
in terms of declarative programming tests, such as xml (XAML, etc.)
testing.

>  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.

I'm not sure what this means exactly... but it doesn't sound bad. :-)

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

Isn't that always the case? :-)

-Kelly

-------------------------------------------------------------------------
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/