Telerik blogs

When asserting an expected call for its number of occurrences or may be just to verify if the setup/arrange is acted as intended, the tool generally raises assertion that points us to the reason why the test failed. Different mocking tools use different exception classes therefore there is no common way to consolidate them.

However, if we just take a look into the test framework unless its some alien one, they all have a common underlying structure for Assert.Throws or ExpectedException (MSTest).

  • MS Test (C# and Silverlight)
    • Microsoft.VisualStudio.TestTools.UnitTesting.AssertFailedException
  • NUnit
    • NUnit.Framework.AssertionException
  • XUnit
    • Xunit.Sdk.AssertException
  • MSpec
    • Machine.Specifications.SpecificationException
  • MbUnit
    • Gallio.Framework.Assertions.AssertionException

So the point here is that if we just use the existing exception class rather than thinking one of our own, it greatly increases the scope of the tooling support. For example, let’s consider the “Test Results” window inside visual studio 2010 that tells us that Foo.Echo() is never invoked as it is expected. Since, its just one line and shows only the reason rather the whole stack trace, it is definitely more user-friendly:




Comparing to the one below, for which you even need to expand and see what’s going wrong.




Here I mentioned the word “increased tooling support”, of course it means the tool vendors (who are creating runners) never need to know which mocking tool and update their formatting code over considering  a test framework.

Technically , JustMock dynamically probes the underlying framework which is the idea very much got from this  project at codeplex which I would like to point here:


The feature is available from Q3 2011 in JustMock Free as well as in commercial edition.

Hope that helps


Comments are disabled in preview mode.