I want to define some new kinds of tests (ala RowTest) for a TestFixture
that cannot be handled by test decorators because I want to bind values
to test method parameters in a different way. Unfortunately the design
of TestFixtureAttribute forbids it.
Right now I just need the TestFixtureAttribute to not be sealed so that
I can extend it, or the TestRun, RowRun and CombinatorialRun classes to
not be internal so I can re-use them.
For those who are interested, I'm working on a simpler data-driven test
mechanism for our Quality Engineering group that does not require as
much boilerplate as the built-in MbUnit stuff. Also because QE is using
MbUnit to automate system tests they are exposed to environmental
dependencies I want to factor out into configuration files or in-line
configuration data. (This is not a problem for most of our unit tests
of course because we can use mocks and other tricks.)
A typical test looks something like the following. Notice the RowTest
pattern at work here.
[DataTest]
[DevData("foo", "bar")] // used for development environment
[LiveData("baz", "blah")] // used for production environment
public void SignIn(string username, string password)
{
}
But data can be sourced from a file also.
[DataTest]
[DevDataSource("credentials.dev.xml")]
[LiveDataSource("credentials.live.xml")]
public void SignIn(string username, string password)
{
}
For data-driven tests (and combinatorial variants thereof) I've started
to think of a more general pattern for binding values to test method
parameters and test fixture properties. Really, that's most of what the
TypeFixture and other MbUnit goodies are accomplishing. However because
MbUnit is not using a common extensible mechanism to achieve this
binding, we cannot mix-and-match test attributes from different types of
fixtures.
Phil's recent question is an example of this problem because he's
finding he cannot use TypeFixture and RowTest together.
For v3, I think we should try to make test data binding orthogonal with
respect to test execution. I have a few ideas about how we might
implement such a notion.
Jeff.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"MbUnit.User" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/MbUnitUser
-~----------~----~----~----~------~----~------~--~---
