Telerik blogs

Previously, i made a post  showing how you can leverage the dependent interfaces that is implemented by JustMock during the creation of mock instance. It could be a informative post that let you understand how JustMock behaves internally for classes or interfaces implement other interfaces into it. But the question remains, how you can add your own custom interface to your target mock. In this post, i am going to show you just that.

Today, i will not start with a dummy class as usual rather i will use two most common interfaces in the .NET framework  and create a mock combining them. Before, i start i would like to point out that in the most recent release of JustMock we have extended the Mock.Create<T>(..) with support for additional settings though closure. You can add your own custom interfaces , specify directly the real constructor that should be called or even set the behavior of your mock.

Doing a fast forward directly to the point,  here goes the test code for create a creating a mock that contains the mix for ICloneable and IDisposable using the above mentioned changeset.

  1. var myMock = Mock.Create<IDisposable>(x => x.Implements<ICloneable>());
  2. var myMockAsClonable = myMock as ICloneable;
  3. bool isCloned = false;
  5. Mock.Arrange(() => myMockAsClonable.Clone()).DoInstead(() => isCloned = true);
  7. myMockAsClonable.Clone();
  9. Assert.True(isCloned);


Here, we are creating the target mock for IDisposable and also implementing ICloneable. Finally, using the “as” to get the ICloneable reference then did the usual like arranging it, acting on it and assert if the expectation is met properly.

Similarly, you can do the same for a given class:

  1. var realItem = Mock.Create<RealItem>(x =>
  2. {
  3.     x.Implements<IDisposable>();
  4.     x.CallConstructor(() => new RealItem(0));
  5. });
  6. var iDispose = realItem as IDisposable;
  8. iDispose.Dispose();

You can implement as many as interfaces you want. Here in this rudimentary example, i am also calling the real constructor for a given RealItem class.  This is to mention that you can implement custom interfaces only for non-sealed classes in conjunction with interfaces or less it will end up with an exception (proper). Also, this feature don’t require any profiler, if you are an agile developer or running it inside silverlight runtime feel free to try it turning off the JM add-in :-).

TIP :  Ability to  specify real constructor could be an useful productivity boost in cases for code change where you can re-factor the usage just by one click with your favorite re-factor tool.


That’s it for now. Here goes the link from previous post:




Comments are disabled in preview mode.