I'd like each test Xml in my test directory to be represented by a
Category in the MbUnit GUI utility.  I'd also like each category of
tests to be a subcategory of the test Xml category.  So it should look
something like this:

-MyTestXml1
  - CubeTester
    - CubeTest1
    - CubeTest2
  - QueryTester
    - QueryTest1
    - QueryTest2
-MyTestXml2
  - CubeTester
    - CubeTest1
    - CubeTest2
  - QueryTester
    - QueryTest1
    - QueryTest2
...

The category names "MyTestXml1" and "MyTestXml2" are defined by the
test Xml file.  I'm using MbUnit 2.4 with .NET 1.1 project.  If this
behaviour is not support in v2 can anyone suggest a workaround to
achieve the same result?  This requirement isn't absolutely critical,
but it's possible we'll have a large number of test Xml files, each of
which could have hundreds of tests.

wladek

On Feb 14, 3:55 pm, Jeff Brown <[EMAIL PROTECTED]> wrote:
> Do you mean you want to define the category at runtime somehow?
>
> This is possible in MbUnit v3, dunno about MbUnit v2 offhand, but I seem
> to recall that FixtureCategory support is hardcoded in v2 and can't
> really be extended much.
>
> What effect are you trying to achieve with these categories?
>
> Jeff.
>
> -----Original Message-----
> From: [email protected] [mailto:[EMAIL PROTECTED]
>
> On Behalf Of wladek
> Sent: Thursday, February 14, 2008 11:08 AM
> To: MbUnit.User
> Subject: MbUnit Re: Dynamic TestSuites and Category Names
>
> Is it possible to define the value for the FixtureCategory attribute at
> "test enumeration time" (not sure if i used the correct term, the time
> when TestCases are added to a TestSuite?
>
> On Feb 14, 12:28 pm, "Graham Hay" <[EMAIL PROTECTED]> wrote:
> > The "Misc" category is where the GUI puts tests without a category, if
>
> > you tag your test with
> > [FixtureCategory("MyTestXml1.CubeTester.CubeTest1")] it
> > (should) get its own node in the Category tree...
>
> > On 14/02/2008, wladek <[EMAIL PROTECTED]> wrote:
>
> > > Hello,
>
> > > I've recently started using MbUnit to test some of our backend .NET
> > > olap retrieval code.  We're using MbUnit on .NET 1.1 assemblies.
> > > The tests themselves also must run using .NET 1.1.
>
> > > I've created a an Xml file that represents the cases we want to
> test.
> > > Each Xml file contains 4 different types of tests to test Olap
> > > connections, Queries and ResultSets, Olap Member Specifications, and
>
> > > Writeback operations.  There are a dynamic number of these test xml
> > > files.  My first approach was to have a single point of entry for
> > > MbUnit (in a Manager class) and then 4 seperate helper classes.  The
>
> > > main entry point iterates through a directory, deserializes the Xml
> > > files that represent our test cases, and passes this info (as well
> > > as a single MbUnit.Framework.TestSuite object to each helper class.
>
> > > Each helper class adds the appropriate tests and returns the
> > > TestSuite object back to my Manager class and the process is
> > > repeated for the next type of test.
>
> > > This approach seems to work, however I'd like the ability to
> > > dynamically categorize the tests so they would appear in the GUI
> > > runner as so:
>
> > > MyTestXml1
> > > - CubeTester
> > >   - CubeTest1
> > >   - CubeTest2
> > > - QueryTester
> > >   - QueryTest1
> > >   - QueryTest2
> > > ...
> > > MyTestXml2
> > > - CubeTester
> > >   - CubeTest1
> > >   - CubeTest2
> > > - QueryTester
> > >   - QueryTest1
> > >   - QueryTest2
> > > ...and so on.
>
> > > At the moment i'm maintaining a dot notation for the name of each
> > > test and all tests are located under a single "Misc" category
> > > because there's only the one entry point for MbUnit.  So my results
> look like:
>
> > > Misc
> > > - Manager.TestXml1.CubeTester.CubeTest1
> > > - Manager.TestXml1.CubeTester.CubeTest2
> > > - Manager.TestXml1.QueryTester.QueryTest1
> > > - Manager.TestXml1.QueryTester.QueryTest2
> > > - Manager.TestXml2.CubeTester.CubeTest1
> > > - Manager.TestXml2.CubeTester.CubeTest2
> > > ...
>
> > > I'm a junior developer, so i wouldnt be surprised if you all think
> > > my approach is totally stupid :).  Feel free to school me on how you
>
> > > would implement this testing harness.
>
> > > All and any feedback would be appreciated, thanks!
>
> > > Sean
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to