.Net, C#, Coding, MbUnit, TDD

Explaining MbUnit GUI tree.

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.


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", https://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 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")]


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


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.


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


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))]


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


10 thoughts on “Explaining MbUnit GUI tree.

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

  2. 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.

    1. 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.

  3. PLS, I just tried syntax below and it worked.

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

      <Test()> _
      Public Sub Test()

      End Sub
    End Class

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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s