Re: Extension Points in NUnit 2.5

Hi All.

Some time ago i implemented NUnit addin which runs NUnitLite tests
on device remotely. Right now that addin can act as TestDecorator and
modify .NET 2.0 test with tests loaded from device (.NET CF 2.0). You just
mark any method with attribute (reference to NUnitLite tests in local
system)
and addin will deploy NUnitLite test assembly to device, build tests from
it,
give results to addin (send actual tests tree of NUnitLite assembly), after
that
tests can be run. I used open serialization library and request\response
based
transport with sockets.

So i want to notice about some problems i have right now with extension
points
and my addin.

First problem is i need to connect\disconnect for each test run (for example
if
user wants to run group of tests and runs an test suite). When connecting to
device i'm checking validity - is test exists at device side or not, is test
assembly
exactly same as i want (crc checks (actually versions can be same)) -
actually i
can do that one time at startup
(when tests is loaded). That can take long time to complete.
So i need way to know about tests reloading\unloading in
NUnit GUI. That should be something like EventListener maybe, or improved
EventListener.
Is there any way to do that? If i implement IDisposable in my proxy tests
will it
be called by core?

Also when connection to device is totally lost (disabled wi-fi for example),
i need
any way to cancel all tests execution (which are not run yet), and mark that
tests as non-executed. I can do that myself by caching some member like
disconnected = true
in my tests (actually all tests loaded to GUI is just my proxy tests). But
anyway i think
this is not best way, and i need some way to cancel all tests which is not
run yet with one
step. That
maybe can be any specialized exception for example (maybe). Is there any
good way?

Also i used NLog for .NET CF at device side. Is there any nlog4net
implementation for
.NET CF so i can connect them (desktop GUI (NUnit core) and device test
runner)
together to not implement remote logs retrieving by myself ? Or is there any
way to listen
for specified port in nlog4net ? (i'm not sure i must ask there about this
part of problems,
but maybe someone knows).

2008/2/27, Charlie Poole <[email protected]>:
>
> 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/
> _______________________________________________
> nunit-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nunit-developer
>



-- 
Best regards,
--------------------------
Zaripov Rinat R. | [email protected]
.NET developer | Russia

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

_______________________________________________
nunit-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nunit-developer