Are you tired of using the object property in MOQ?
Are you tired of declaring a huge amount of local variables to declare complex hierarchies?
…
Have a look at the new Mock.Of<T> feature in MOQ! Let’s see an example.
Did you had the problem your mock must act like a bean? And you could not create the object with the real implementation? And the interface was too large, so you would not create a innerclass for the test? I had this problem too. I solved it with the answer in mockito.
To continue my series on Mocking Katas (see Mocking Kata – Instrument Processor for the last Kata), I’ll show you a very simple Kata that I normally use in my Test Driven Development training courses to introduce mocks (created manually or dynamically with the use of a mocking framework): the CharacterCopier.
We use Coding Katas in Coding Dojos to improve our programming skills. This includes skills in software design, refactoring, Test Driven Development, Mocking, tool usage and a lot of other tiny stuff.
However, I found only a few Katas, especially Katas including the need for mocks (see for example http://codingkata.org/). Most Katas are very algorithmic, which is good for learning TDD. But its bad for learning how to use mocks.
Therefore, I started to invent my own Mocking Katas. I use these in my training courses on Test Driven Development.
I must say I’m really a huge fan of Moq. Moq is steady growing and the developer community is quite impressive in inventing new features and extensions. I recently ran over a nice feature suggestion placed in a private branch from moq. The branch belongs to Brian J. Cardiff. I suggest you check also his blog out! The feature brain suggested is an extension method which allows to do sequential setups. The sequential setup allows to specify in a fluent way for example different return types on a mock for each call. Let’s have an example!
NMock2 is a library for assisting test driven development of .NET code by providing a dynamic mock object creation framework.
In my last post on NMock2, I introduced the new Stub feature of NMock2 and its basic usage. In the second part, we are going to have a look at the advanced possibilities of the Stub mock style:
Due to changes on sourceforge.net and its hosted applications, the documentation of NMock2 – a library for assisting test driven development of .NET code by providing a dynamic Mock Object framework for .NET interfaces and classes (virtual and abstract members of classes) – has been moved from WikiSpaces to MediaWiki.
You can check it out at http://sourceforge.net/apps/mediawiki/nmock2/index.php?title=Main_Page
NMock2 is a library for assisting test driven development of .NET code by providing a dynamic mock object creation framework.
In this article, I’m going to show you the basics of the new stub feature in NMock2. Note that this feature is currently only available on the development trunk in the subversion repository at https://nmock2.svn.sourceforge.net/svnroot/nmock2/trunk. Therefore, the features discussed here may change for the next official release.
Stubs can be used in scenarios where you have to test an instance of a class (let’s call this object testee) and this testee makes calls to another object (dependency) but you simply do not care what the testee calls on the dependency because it is not relevant for your test case.
Stubs will simply ignore any calls to it and if the call has a return value then the stub provides a default value.