Vadim's Weblog

Never stop learning.

Explaining MbUnit GUI tree.

Posted by Vadim on September 29, 2007

When the first time I looked at MbUnit GUI tool, I was overwhelmed with complex tree structure. The root has five branches: Authors, MbUnitGuiColapsedTreeCategories, Importances, Namespaces, and TestsOns. I was able relate to Namespaces and Categories; I’ve seen something similar in NUnit. But what for are other three branches. Well, MbUnit GUI shows the branches in alphabetical order. There for I’ll try explain the branches in the same order. I’ll start with Authors and end with TestsOns.

Authors

It’s pretty clear that if you want to claim ownership of the test fixture you need to put it inside the Authors. It’s not hard to do. What you need to do is to use Author attribute on your fixture. Author attribute has three overloads:

   1: [TestFixture]

   2: [Author("Vadim")]
   3: public class MyTest {}

 

   1: [Author(“Vadim”, “vadim@domain.com”)]

   2: [Author("Vadim", "vadim@domain.com", http://vkreynin.wordpress.com/)]

MbUnitGuiAuthors Before we added Author(“Vadim”), we had “Anonymous” leaf inside the Authors branch. “Anonymous” always will have test fixtures that don’t have an Author attribute. I believe it’s a good practice to use this attribute on big projects. However, instead of a person name I would use a team name. The reason I think it should be a team name because a developer can switch a team, find a better job or win a lottery and leave the team. A team is responsible for the part of the project they are working on and there for they also should be responsible for the tests. Also a team probably would like to run all the tests related to the team before checking in the code.

Categories

Categories branch is obviously for categorized test fixtures. You can assign multiple categories to a test fixture. Here how you do it using FixtureCategory attribute.

   1: [TestFixture]
   2: [FixtureCategory("Demo")]
   3: [FixtureCategory("WebPayroll")]

MbUnitGuiCategories

All the test fixtures that don’t have a category assigned can be found in Categories/Misc branch.

Importances

This branch specifies the importance of the test fixture. MbUnit Framework defines five different types of test fixture importance.

  • Critical
  • Default
  • NoOneReallyCaresAbout
  • Serious
  • Severe

Importance can be defined by Importance attribute.

   1: [TestFixture]
   2: [Importance(TestImportance.Severe)]

The test fixtures that don’t have importance can be found in Default importance. To be honest I didn’t find it very useful yet. Let me know how you use this attribute.

Namespaces

I don’t think that I need to explain this. Anybody who develops using .NET know what Namespace is.

TestsOns

For some reason this one took me the longest to figure out. Using TestsOn attribute you can specify what class the test fixture is testing.

   1: [TestFixture]
   2: [TestsOn(typeof(Employee))]

MbUnitGuiTestsOns

In the example above we are saying that the test fixture is testing Employee class. All the test fixtures that don’t use TestsOn attribute can be found in Unknown branch.

kick it on DotNetKicks.com

About these ads

9 Responses to “Explaining MbUnit GUI tree.”

  1. Peli said

    Ooops, I might have gone overboard when I designed the UI :)
    Importance should probably be renamed ‘Suite’ and structure in ‘Build, Checkin, TheRest’…

  2. vkreynin said

    Peli, what would you use ‘Suite’ for?

  3. Jeff Brown said

    Of course as you know the metadata story in MbUnit Gallio is much more powerful. Likewise we’ll probably opt for some other GUI filtering mechanism because the tree has proven too confusing and hard to use (trust me, you’re not the only one).

    I’ve never found TestImportance useful myself but for system testing I’d be very keen to have a Suite attribute (smoke tests, functional tests, post-deployment tests, stress tests, …). Likewise I’m looking forward to slicing and dicing based on Feature and Product metadata.

    The whole idea with Gallio metadata is to allow users of the framework to define their own conventions appropriately for their needs.

    • Mona said

      I kind of agree and I am looking for option as BVT, Smoke, Acceptance test etc. currently I have workaround as [FixtureCategory(“BVT”)]so on UI, it shows as “BVT”.

      Also, I am looking for some way to categorize individual test cases in a class. My current automation suit may not be best designed so I am exploring all options.

  4. PLS said

    What would be the visual basic version of [TestsOn(typeOf(Employee))]?

    doesn’t work.

  5. vkreynin said

    I believe that VB.Net syntax will be .

  6. PLS said

    vkreymin, your last response was incomplete. I used
    but kept getting a
    syntax error. Any ideas? Thanks.

  7. vkreynin said

    PLS, I just tried syntax below and it worked.

    <TestFixture(), TestsOn(GetType(String))> _
    Public Class Class1

      <Test()> _
      Public Sub Test()

      End Sub
    End Class

  8. This is fantastic. Thanks!

    — Lee

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
Follow

Get every new post delivered to your Inbox.

%d bloggers like this: