Discussion:
Recent 2.5 Changes
Charlie Poole
2008-07-28 20:20:04 UTC
Permalink
Hi All,

As usual, this is for those who track the CVS source. The
rest will have to wait for alpha-4, but it shouldn't be
too long...

1. Classes can have multiple setup, teardown, fixture setup
or fixture teardown methods. Base setups are run before
the derived setup and teardowns are run in reverse. Within
the same class declaration, order is undefined, so it's not
too useful but still possible.

NOTE: If you /override/ a base class method, you don't have
two methods any more, so only the override runs. Do that
if that's what you want, otherwise don't. :-)

2. DataSourceAttribute provides a way to point to data
for individual arguments just as FactoriesAttribute (I
still don't like that name) points to entire test cases.

3. TestFixtures can now have parameters, which are used
in searching for a constructor. You repeat [TestFixture(...)]
just as you do for [TestCase(...)] and each individualized
fixture is created separately in the tree.

4. We already had generic fixtures and now they can have
parameters too. You can specify what types to use in
creating a specific class from the generic declaration
in three ways...

1) By preceding the constructor args with a set of
Types to be used. This won't work if the first
constructor arg is a Type, of course.

2) By using the TypeArgs named property of TestFixtureAttribute

3) By using a constructor that makes use of all the
Type parameters - in that case NUnit will figure
it out.

I'm aware that the last bit particuarly needs documentation.
Consider the above as hints for the brave among you.

Charlie





-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Olof Bjarnason
2008-07-28 20:36:15 UTC
Permalink
Post by Charlie Poole
Hi All,
As usual, this is for those who track the CVS source. The
rest will have to wait for alpha-4, but it shouldn't be
too long...
1. Classes can have multiple setup, teardown, fixture setup
or fixture teardown methods. Base setups are run before
the derived setup and teardowns are run in reverse. Within
the same class declaration, order is undefined, so it's not
too useful but still possible.
Is there a specific reason why multiple setups/teardowns per fixture
is at all allowed? I would prefer one-setup-per-fixture instead of
undefined behaviour.
Post by Charlie Poole
NOTE: If you /override/ a base class method, you don't have
two methods any more, so only the override runs. Do that
if that's what you want, otherwise don't. :-)
2. DataSourceAttribute provides a way to point to data
for individual arguments just as FactoriesAttribute (I
still don't like that name) points to entire test cases.
Could you provide a very brief syntax example of this?
Post by Charlie Poole
3. TestFixtures can now have parameters, which are used
in searching for a constructor. You repeat [TestFixture(...)]
just as you do for [TestCase(...)] and each individualized
fixture is created separately in the tree.
Cool! So if I have several classes implementing an interface that
should adhere to specific rules specified by tests, I could
parameterize the fixture containing those tests with the specific
class implementations? Great!
Post by Charlie Poole
4. We already had generic fixtures and now they can have
parameters too. You can specify what types to use in
creating a specific class from the generic declaration
in three ways...
I have no clue what you are talking about, but I guess it's great ;)
Post by Charlie Poole
1) By preceding the constructor args with a set of
Types to be used. This won't work if the first
constructor arg is a Type, of course.
2) By using the TypeArgs named property of TestFixtureAttribute
3) By using a constructor that makes use of all the
Type parameters - in that case NUnit will figure
it out.
I'm aware that the last bit particuarly needs documentation.
Consider the above as hints for the brave among you.
Charlie
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
nunit-developer mailing list
https://lists.sourceforge.net/lists/listinfo/nunit-developer
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Charlie Poole
2008-07-28 20:53:35 UTC
Permalink
Hi Olof,
Post by Charlie Poole
As usual, this is for those who track the CVS source. The rest will
have to wait for alpha-4, but it shouldn't be too long...
1. Classes can have multiple setup, teardown, fixture setup
or fixture
teardown methods. Base setups are run before the derived setup and
teardowns are run in reverse. Within the same class
declaration, order
is undefined, so it's not too useful but still possible.
Is there a specific reason why multiple setups/teardowns per
fixture is at all allowed? I would prefer
one-setup-per-fixture instead of undefined behaviour.
1. Some folks have asked for it so as to segregate unrelated
setups in different methods - even in different files in
the case of partial classes. In such cases, undefined
order is not a problem.

2. It's consistent with NUnit moving away from a philosophy of
"we won't give you anything you could hurt yourself with" to
"it's up to you what you do with the tool."

3. It simplifies the code if I don't have to check this.
Post by Charlie Poole
NOTE: If you /override/ a base class method, you don't have two
methods any more, so only the override runs. Do that if that's what
you want, otherwise don't. :-)
2. DataSourceAttribute provides a way to point to data for
individual
arguments just as FactoriesAttribute (I still don't like that name)
points to entire test cases.
Could you provide a very brief syntax example of this?
[DataSource("MyData")]

FWIW, I find inline data much more conducive to doing TDD. However,
there can be a need to share data across multiple tests.

Charlie
Post by Charlie Poole
3. TestFixtures can now have parameters, which are used in
searching
for a constructor. You repeat [TestFixture(...)] just as you do for
[TestCase(...)] and each individualized fixture is created
separately
in the tree.
Cool! So if I have several classes implementing an interface
that should adhere to specific rules specified by tests, I
could parameterize the fixture containing those tests with
the specific class implementations? Great!
4. We already had generic fixtures and now they can have parameters
too. You can specify what types to use in creating a specific class
from the generic declaration in three ways...
I have no clue what you are talking about, but I guess it's great ;)
1) By preceding the constructor args with a set of
Types to be used. This won't work if the first
constructor arg is a Type, of course.
2) By using the TypeArgs named property of TestFixtureAttribute
3) By using a constructor that makes use of all the
Type parameters - in that case NUnit will figure
it out.
I'm aware that the last bit particuarly needs documentation.
Consider the above as hints for the brave among you.
Charlie
----------------------------------------------------------------------
--- This SF.Net email is sponsored by the Moblin Your Move
Developer's
challenge Build the coolest Linux based applications with
Moblin SDK &
win great prizes Grand prize is a trip for two to an Open
Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
nunit-developer mailing list
https://lists.sourceforge.net/lists/listinfo/nunit-developer
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Olof Bjarnason
2008-07-28 21:14:18 UTC
Permalink
Post by Charlie Poole
Hi Olof,
Post by Charlie Poole
As usual, this is for those who track the CVS source. The rest will
have to wait for alpha-4, but it shouldn't be too long...
1. Classes can have multiple setup, teardown, fixture setup
or fixture
teardown methods. Base setups are run before the derived setup and
teardowns are run in reverse. Within the same class
declaration, order
is undefined, so it's not too useful but still possible.
Is there a specific reason why multiple setups/teardowns per
fixture is at all allowed? I would prefer
one-setup-per-fixture instead of undefined behaviour.
1. Some folks have asked for it so as to segregate unrelated
setups in different methods - even in different files in
the case of partial classes. In such cases, undefined
order is not a problem.
2. It's consistent with NUnit moving away from a philosophy of
"we won't give you anything you could hurt yourself with" to
"it's up to you what you do with the tool."
3. It simplifies the code if I don't have to check this.
Post by Charlie Poole
NOTE: If you /override/ a base class method, you don't have two
methods any more, so only the override runs. Do that if that's what
you want, otherwise don't. :-)
2. DataSourceAttribute provides a way to point to data for
individual
arguments just as FactoriesAttribute (I still don't like that name)
points to entire test cases.
Could you provide a very brief syntax example of this?
[DataSource("MyData")]
Could you elaborate a little bit? What is "MyData"? Is it the name of
a member variable, or maybe an IEnumerable field attributed by a some
kind of name-attribute with the string "MyData"?
Post by Charlie Poole
FWIW, I find inline data much more conducive to doing TDD. However,
there can be a need to share data across multiple tests.
Charlie
Post by Charlie Poole
3. TestFixtures can now have parameters, which are used in
searching
for a constructor. You repeat [TestFixture(...)] just as you do for
[TestCase(...)] and each individualized fixture is created
separately
in the tree.
Cool! So if I have several classes implementing an interface
that should adhere to specific rules specified by tests, I
could parameterize the fixture containing those tests with
the specific class implementations? Great!
4. We already had generic fixtures and now they can have parameters
too. You can specify what types to use in creating a specific class
from the generic declaration in three ways...
I have no clue what you are talking about, but I guess it's great ;)
1) By preceding the constructor args with a set of
Types to be used. This won't work if the first
constructor arg is a Type, of course.
2) By using the TypeArgs named property of TestFixtureAttribute
3) By using a constructor that makes use of all the
Type parameters - in that case NUnit will figure
it out.
I'm aware that the last bit particuarly needs documentation.
Consider the above as hints for the brave among you.
Charlie
----------------------------------------------------------------------
--- This SF.Net email is sponsored by the Moblin Your Move
Developer's
challenge Build the coolest Linux based applications with
Moblin SDK &
win great prizes Grand prize is a trip for two to an Open
Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
nunit-developer mailing list
https://lists.sourceforge.net/lists/listinfo/nunit-developer
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Charlie Poole
2008-07-28 22:20:06 UTC
Permalink
Hi Olof,
-----Original Message-----
Sent: Monday, July 28, 2008 2:14 PM
To: Charlie Poole
Subject: Re: [nunit-developer] Recent 2.5 Changes
Post by Charlie Poole
Post by Charlie Poole
2. DataSourceAttribute provides a way to point to data for
individual
arguments just as FactoriesAttribute (I still don't like
that name)
Post by Charlie Poole
Post by Charlie Poole
points to entire test cases.
Could you provide a very brief syntax example of this?
[DataSource("MyData")]
Could you elaborate a little bit? What is "MyData"? Is it the
name of a member variable, or maybe an IEnumerable field
attributed by a some kind of name-attribute with the string "MyData"?
Sorry, I was assuming familiarity with FactoriesAttribute, which uses
the same syntax... But try this...

http://nunit.org/index.php?p=dataSource&r=2.5

Note that that page is not linked into the navigation, since the
web site actually represents the Alpha-3 release.

Charlie
Post by Charlie Poole
FWIW, I find inline data much more conducive to doing TDD. However,
there can be a need to share data across multiple tests.
Charlie
Post by Charlie Poole
3. TestFixtures can now have parameters, which are used in
searching
for a constructor. You repeat [TestFixture(...)] just as
you do for
Post by Charlie Poole
Post by Charlie Poole
[TestCase(...)] and each individualized fixture is created
separately
in the tree.
Cool! So if I have several classes implementing an interface that
should adhere to specific rules specified by tests, I could
parameterize the fixture containing those tests with the specific
class implementations? Great!
4. We already had generic fixtures and now they can have
parameters
Post by Charlie Poole
Post by Charlie Poole
too. You can specify what types to use in creating a
specific class
Post by Charlie Poole
Post by Charlie Poole
from the generic declaration in three ways...
I have no clue what you are talking about, but I guess
it's great ;)
Post by Charlie Poole
Post by Charlie Poole
1) By preceding the constructor args with a set of
Types to be used. This won't work if the first
constructor arg is a Type, of course.
2) By using the TypeArgs named property of TestFixtureAttribute
3) By using a constructor that makes use of all the
Type parameters - in that case NUnit will figure
it out.
I'm aware that the last bit particuarly needs documentation.
Consider the above as hints for the brave among you.
Charlie
---------------------------------------------------------------------
Post by Charlie Poole
Post by Charlie Poole
-
--- This SF.Net email is sponsored by the Moblin Your Move
Developer's
challenge Build the coolest Linux based applications with
Moblin SDK &
win great prizes Grand prize is a trip for two to an Open
Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
nunit-developer mailing list
https://lists.sourceforge.net/lists/listinfo/nunit-developer
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Charlie Poole
2008-07-28 22:19:37 UTC
Permalink
Hi Olof,

I missed seeing part of your note the first time...
Post by Charlie Poole
3. TestFixtures can now have parameters, which are used in
searching
for a constructor. You repeat [TestFixture(...)] just as you do for
[TestCase(...)] and each individualized fixture is created
separately
in the tree.
Cool! So if I have several classes implementing an interface
that should adhere to specific rules specified by tests, I
could parameterize the fixture containing those tests with
the specific class implementations? Great!
Exactly. Of course, #4 makes it even cooler!
Post by Charlie Poole
4. We already had generic fixtures and now they can have parameters
too. You can specify what types to use in creating a specific class
from the generic declaration in three ways...
I have no clue what you are talking about, but I guess it's great ;)
"types to use" == "type arguments" == "stuff you would normally
put in angle brackets" :-)

If this seems roundabout, it is, but it as to be because .NET
doesn't allow attributes to be generic.
Post by Charlie Poole
1) By preceding the constructor args with a set of
Types to be used. This won't work if the first
constructor arg is a Type, of course.
2) By using the TypeArgs named property of TestFixtureAttribute
3) By using a constructor that makes use of all the
Type parameters - in that case NUnit will figure
it out.
I'm aware that the last bit particuarly needs documentation.
Consider the above as hints for the brave among you.
Charlie
----------------------------------------------------------------------
--- This SF.Net email is sponsored by the Moblin Your Move
Developer's
challenge Build the coolest Linux based applications with
Moblin SDK &
win great prizes Grand prize is a trip for two to an Open
Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
nunit-developer mailing list
https://lists.sourceforge.net/lists/listinfo/nunit-developer
--------------------------------------------------------------
-----------
This SF.Net email is sponsored by the Moblin Your Move
Developer's challenge Build the coolest Linux based
applications with Moblin SDK & win great prizes Grand prize
is a trip for two to an Open Source event anywhere in the
world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
nunit-developer mailing list
https://lists.sourceforge.net/lists/listinfo/nunit-developer
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Charlie Poole
2008-07-28 21:04:10 UTC
Permalink
BTW, I updated the roadmap at http://nunit.org/?p=roadmap - it had
gotten seriously out of date.

Charlie
-----Original Message-----
Behalf Of Charlie Poole
Sent: Monday, July 28, 2008 1:20 PM
Subject: [nunit-developer] Recent 2.5 Changes
Hi All,
As usual, this is for those who track the CVS source. The
rest will have to wait for alpha-4, but it shouldn't be too long...
1. Classes can have multiple setup, teardown, fixture setup
or fixture teardown methods. Base setups are run before the
derived setup and teardowns are run in reverse. Within the
same class declaration, order is undefined, so it's not too
useful but still possible.
NOTE: If you /override/ a base class method, you don't have
two methods any more, so only the override runs. Do that if
that's what you want, otherwise don't. :-)
2. DataSourceAttribute provides a way to point to data for
individual arguments just as FactoriesAttribute (I still
don't like that name) points to entire test cases.
3. TestFixtures can now have parameters, which are used in
searching for a constructor. You repeat [TestFixture(...)]
just as you do for [TestCase(...)] and each individualized
fixture is created separately in the tree.
4. We already had generic fixtures and now they can have
parameters too. You can specify what types to use in creating
a specific class from the generic declaration in three ways...
1) By preceding the constructor args with a set of
Types to be used. This won't work if the first
constructor arg is a Type, of course.
2) By using the TypeArgs named property of TestFixtureAttribute
3) By using a constructor that makes use of all the
Type parameters - in that case NUnit will figure
it out.
I'm aware that the last bit particuarly needs documentation.
Consider the above as hints for the brave among you.
Charlie
--------------------------------------------------------------
-----------
This SF.Net email is sponsored by the Moblin Your Move
Developer's challenge Build the coolest Linux based
applications with Moblin SDK & win great prizes Grand prize
is a trip for two to an Open Source event anywhere in the
world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
nunit-developer mailing list
https://lists.sourceforge.net/lists/listinfo/nunit-developer
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Loading...