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.
This is a small summarization what the differences are between the different variations creating mocks with mockito.
Per default, after creating a mock, every method will return null. Just create your mock with:
Sample sample = Mockito.mock(ISample.class);
I think, this is very useful and straight forward. (And based by mockito developers idea, to create very fast a mock for testing). Sometimes it is very difficult to determine an error which was produced through such a null value. For this case it is very practicable to tell mockito, returning SmartNullValues.
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!
How to find a concurrency bug – this was the question I asked myself some time ago.
It is always very hard to find a concurrency bug. Mostly you have no idea when it happens or if it is really a concurrency issue or some nasty bit of code. If it is a concurrency issue the question is if the bug is in your code or in a supplied library? Will the problem happen only on multicore processors or on any machine? Besides the technical problem the customer is eager to get a solution and management… we’ll i guess you know the story.
I won’t be able to tell you everything there is to know about concurrency testing – but I’ll show you a way that worked for me in most cases.
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:
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.
When I’m coaching teams in Test Driven Development (TDD), I’m often asked how to deal with the User Interface (UI). The problem is that the unit test frameworks are weak in testing Forms, Controls, Buttons, Grids, and so on. Weak because they do not support it at all or the tests become very fragile (e.g. renaming a Label causes the test to fail).
We address this problem with the Passive View Command pattern, PVC for short.
A few weeks ago, I started using Mockito. Mockito is a mocking framework for Java.
What mockito is able to do:
- mocking interfaces and abstract classes
- mocking concrete classes
- spy real objects
(http://code.google.com/p/mockito)
I liked mockito so much that I decided to present it to you…
Andrew Kazyrevich published a post containing timing comparisons of Moq, Rhino Mocks, Isolator and NMock2.
And NMock2 – although still lacking some features – is very fast compared to the competitors. Woohoo!
I’m curious how the newly introduced features (mock classes, non-strict and recursive mocks) will change in this setup. I’ll check that out as soon as I find some time :-O
If you want to check the new features (alpha!) yourself then here is the svn URL: https://nmock2.svn.sourceforge.net/svnroot/nmock2/branches/nonstrictmocks
Happy mocking!