Duplicate TestFixtures not supported

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Setup a testfixture using generics such as [TestFixture("iexplore", "8.0")]
2. Duplicate that testfixture.
3. Does not compile. 

What is the expected output? What do you see instead?
Using NUnit, you can stack testfixtures in this manner around the same tests.  
This is very useful when using generics as above to run the same set of tests 
with variable parameters.  In my case, I'm using this to run the same set of 
tests against multiple browsers using Selenium. 

What version of the product are you using? On what operating system?
Gallio 3.3.458.0 package

Please provide any additional information below.
This may be an enhancement.  I'm unsure, but I'd love to see this work so that 
I can leverage the parallelization tools of MbUnit against my tests...

Original issue reported on code.google.com by dave.r...@gmail.com on 20 Jan 2012 at 2:46

[GoogleCodeExporter]

Do you mean TestCase? Try [Row("blah")].

Original comment by grahamr...@gmail.com on 20 Jan 2012 at 3:45

[GoogleCodeExporter]

Nope, I'm using generics for my testfixtures, but then using tests that go out 
and get app config.  I haven't used Rows and columns yet, but I can take a look 
there.  Just easing into the migration from NUnit to MbUnit. Is that the way to 
go?

My structure looks like this:
<!----------------------------------------------------------------------------->

[SetUpFixture]
  [SetUp]
  foo(){}

  [TestFixture("iexplore", "8.0")]
  [TestFixture("iexplore", "9.0")]
  [TestFixture("firefox", "9.0")]
    public class SmokeTest<TB, TV>
    {
        //Test fixture variables
        private string browser;
        private string version;

        public SmokeTest(TB b, TV v)
        {
            browser = b.ToString();
            version = v.ToString();

        }
        [SetUp]
        bar(){}

        [TearDown]
        teardown(){}

        [Test]
        someTest(){
            var keyList = ConfigurationManager.AppSettings.Get(Core.TestName);

            //Run test if in support institution list
            if (!keyList.Split(',').Contains(institution))
                throw new IgnoreException(institution + " does not support the " + Core.TestName + " test. Test ignored for " + Core.Browser + ". ");

        }

        [Test]
        someOtherTest(){}

        [Test]
        someOtherOtherTest(){}

<!----------------------------------------------------------------------------->

I'm suppressing some other things that we pass in along the way, but this is 
what my nUnit-friendly tests look like... not sure if this helps. Thanks for 
the feedback regardless. 

Original comment by dave.r...@gmail.com on 20 Jan 2012 at 4:18

[GoogleCodeExporter]

This could be because you've simplified the example, but what's the point of 
the generics? (If it's always a string?)

Original comment by grahamr...@gmail.com on 20 Jan 2012 at 4:41

[GoogleCodeExporter]

Absolutely.  I have to omit some code as I have strings that indicate some 
client names.  Just avoiding the association.  

I pass those into a function that creates a remote webdriver.  These strings 
set my capabilities for that remotewebdriver.  This allows me to run the same 
set of tests against my Grid, and therefore against all of my supported 
browsers.  Adding support for a new browser to my tests is as simple as putting 
up a server and adding a test fixture line to my tests. 

Original comment by dave.r...@gmail.com on 20 Jan 2012 at 4:58

[GoogleCodeExporter]

I'm still not entirely clear what you're trying to achieve. Is TB/TV ever any 
type other than string? When do you call the function to build the webdriver, 
inside the fixture or outside?

Original comment by grahamr...@gmail.com on 20 Jan 2012 at 5:33

[GoogleCodeExporter]

Does the second half of this article: 

http://www.developerfusion.com/article/128726/web-testing-with-mbunit-and-watin-
part-1-keeping-your-tests-legible/

help? Is that what you are trying to achieve?

Original comment by grahamr...@gmail.com on 20 Jan 2012 at 5:36

[GoogleCodeExporter]

My concern is not about making my rests legible or organized.  They're actually 
quite organized and clear, easy to maintain, and easy to extend.  My goal is to 
bastardize MbUnit's ability to run tests in parallel since I have the resources 
to support is from a hardware perspective.  The endgame is that my tests can 
run quicker.  

Using NUnit, you can stack test fixtures and pass in generics, then do whatever 
you want.  In my case, this drives my RemoteWebDriver capabilities as well as 
my supported environments (each customer has their own independent 
environment). \

My Core/Driver creation occurs in my Setup, which is within the fixtures (NOT 
setuptextfixture).  It creates a new driver for each test, which allows me to 
do things before and after each test like logging, setup tasks, etc.

Original comment by dave.r...@gmail.com on 20 Jan 2012 at 5:45

[GoogleCodeExporter]

It was more the generic test fixture I was suggesting you look at.

It is possible to have generic fixtures in MbUnit, but they expect types rather 
than strings e.g.

    [TestFixture]
    [Row(typeof(string), typeof(string))]
    public class Fixture<T1, T2>
    {
        [SetUp]
        public void SetUp()
        {
            Console.WriteLine(typeof(T1));
            Console.WriteLine(typeof(T2));
        }

        [Test]
        public void Test()
        {
        }
    }

If you just want strings, then you don't need the generics:

    [TestFixture]
    [Row("one", "two")]
    public class Fixture
    {
        public Fixture(string one, string two)
        {
            Console.WriteLine(one);
            Console.WriteLine(two);
        }

        [Test]
        public void Test()
        {
        }
    }

Does that help?

Original comment by grahamr...@gmail.com on 22 Jan 2012 at 11:55