NUnit 2.5 Alpha 1 Release

Charlie Poole

2008-04-28 04:58:06 UTC

Hi Gary,

My guess is that your extension should probably be both a test case

builder

and a data provider, so take a look at the ParameterProviders extension
point.

I've upgraded my theory extension to build and work against the NUnit 2.5
changes, but I haven't made use of any ParameterProvider stuff yet - what
advantage does it give me to do so?
To be more precise: I meant that the InlineData and PropertyData be

handled

by providers, rather than directly in your code. This has
advantages and disadvantages, which probably apply differently to each of
your extensions
PRO
You can reuse code, since NUnitTestMethod now understands providers.

yep, that's the main advantage I saw for the parameterized fixture and test
method.

Your extensions can make use of other data providers, if those providers

are

willing to give you data.

this might work well with the theory extension - I was going to look at the
all-pairs test case generation soon, but it would be easier to defer that
work to later and have it as a separate data provider.

How I was seeing this work though, was to add in a property so that users
can specify data for each parameter independently.

Sure. You could put the property on each arg. Your provider could combine
them in any way it chose, creating as many sets of parameters as it wanted
to.

But also, I wanted to do it for the users example data.
i.e. if a user said I know that my theory is valid for
data set 1:
parameter 1 = 2.0; parameter 2 = 3.0; parameter 3 = 4.0;
data set 2:
parameter 1 = 5.0; parameter 2 = 7.0; parameter 3 = -2.0;

That could be a separate provider - i.e. the InlineData provider. The 2.5
code combines whatever data comes from the various providers.

then I'd respect their choice - make sure that the theory is executed with
these datasets, but I'd like ALSO to include this data in the pairwise
testing data. this would require that the parameterprovider get hold of the
separately provided data. Is this possible?

It's not desirable IMO for more than one provider to deal with the same
data. Let NUnit do the combining.

(Another way to say this is that people can decide to write data
extensions for your provider.)
Other extensions can make use of your data providers, if you allow it.
(So someone could create a new extension from your building blocks)
CON
In 2.5, if you accept any data providers, you have no further control over
which providers supply it.

This means that I could be getting data from anywhere? but I can still
provide my own data provider? (data providers are additive - they just add
data to the pot?)

Yes. In 2.5 (since we don't have addins on addins) if you use the
dataproviders extension point then you are leaving it up to the individual
providers to decide if they want to give you data. They can make that choice
in HasParametersFor. So if you /don't/ want that to happen,
you should not use the extension point. However, there is nothing to
prevent your using the architecture and maintaining your own private list of
data providers in the extension. In 3.0 we'll be able to get fancier.

For my data-driven tests and fixtures, I can see that using the
ParamterProvider lets me re-use code (I can lose my DynamicTestMethod

which

derives from NUnitTestMethod), but for my theory extension, I need to

create

a new TestMethod anyway - not just for the parameters, so it is worth me
going to the efforts of using a parameter provider?
I see the difference. You would have to figure out how much your new

method

differs from a standard method. For example,
you may only need to override the method that translates an exception to a
result state.
Will it give me anything different - it this the way where we'd get the
user's test method invoked for all data sets but only display one entry in
the tree? (and they'd be able to drill down to see all of the data used in
running the test/theory?)
What is currently called ParameterProviders (a better name may be
TestCaseProviders) is an extension point for creating new parameterized
tests in the tree itself. I plan to add another extension point that
provides data at runtime, without creating any
new data in the tree. This would only work for a new type of test case

that

returned multiple results and would require support in
the UI in order to drill down into the results. I feel that's still the
biggest thing missing for the final 2.5 release.
I just downloaded the latest versions of both extensions. I'll post any
further comments as I go through them.
Charlie

Thanks Charlie! I just thought I'd give you a heads up and let you know that
I haven't got my 2.5 version of Maslina online yet.
it works in the same way, the changes were TestCaseResult has been renamed
to TestResult,
and my TestMethod no longer throws an exception in failure - it sets the
TestResult to Success or Failure. I can send you this code in its current
state if you want though.

Yes, the exceptions should only be used from the asserts in the user code
TestCases/TestMethods/TestSuites should set the result.

Oh, strangely, when I installed NUnit 2.5, it didn't install half of the
assemblies into the GAC. I ended up downloading and building the source
anyway (it's easier to figure out what's changed by seeing what exceptions
are thrown from the middle of NUnit), but is the installer broken? (I can
still run the install of NUnit, but not reference the ocre assemblies).

NUnit hasn't been installing /any/ assemblies in the GAC for quite a few
years. I'm guessing you mean that fewer assemblies were showing up in the VS
add reference dialog. That's actually a different mechanism from the GAC.
And the change is by design. It's confusing to most users to have all those
assemblies they should never be referencing. The downside is that extenders
have to browse for them.

Charlie

Thanks again!
Gary

_____

Get fish-slapping on Messenger Play Now! <http://www.fishticuffs.co.uk>