xUnit Cheat Sheet
Here is a draft of my xUnit Cheat sheet
Update: 06.12.2011, added IUseFixture<>
xUnitCheatSheet (Currently V0.2)
Let me know if you have any updates…
Here is a draft of my xUnit Cheat sheet
Update: 06.12.2011, added IUseFixture<>
xUnitCheatSheet (Currently V0.2)
Let me know if you have any updates…
We use a lot of state machines in our projects. We use them for abstracting instruments that we control, controlling when user input controls have to be enabled or disabled and for other things.
State machines are great for these kind of tasks (much easier that nested switch statements anyway) but they provide a big challenge when developing software test driven. This is due to the fact that they are of course very state full and often active (running on their own worker thread).
Here are some best practices leading to maintainable and refactoring friendly unit tests.
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.
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.