jimmy keen

In the following part of mocking frameworks comparison we'll see how to instruct mock objects to raise event and how syntax to do so evolved throughout libraries. Additionally, I'll show varying support for event-subscription testing and how to use it, even though such unit test might have rather questionable value.

Fairly often you have to instruct your mock (stub, actually) to throw. Frameworks in question deal with this requirement in a very similar manner.

Suppose we want to handle a situation when GetCustomer throws exception when Filter parameter is in certain state. This is naturally only useful when we're testing code that reacts to exception being thrown, for example if we had TransactionService that uses IBankService under the hood.

This is a simple tutorial on how to easily migrate your project from SVN to Git local repository. If you've been using TortoiseSVN and you plan to start working with TortoiseGit, you might find out that git clone from SVN command fails with rather strange errors. This is most likely caused by file:/// prefixing used when working with local SVN repositories (which Git seems to not handle well). Read more to find out how to overcome this issue.

When do you write unit test? This fairly easy question, has no universal answer. Do you test everything, going for as high code coverage, or do you test selectively? Do you test simple code? What simple code really means? Do tests have value? In this post I tackle similar questions and try to explain why unit testing is not always obvious and often you will rely on your personal experience than book guidelines.

Having dealt with basic APIs for argument matching in previous parts, now it's the time for a bit more complex scenarios.

As some of you might remember, in first arguments post I've introduced new methods on our exemplary IBankService interface. The very first method was the one taking Filter instance as parameter, however the type itself has never been described. Let's do this now:

We'll take a look at what utility methods for simple constraints frameworks have to offer. Content is relatively easy and I'll stay away from explaining what does what, unless it's necessary.

Having basics covered, we can deal with more complex topics - arguments matching. Let's start with introduction of new methods on IBankService:

Customer GetCustomer(Filter filter);
Customer GetCustomer(IEnumerable<int> numbers);
Customer GetCustomer(string name, int number);

In previous post I introduced motivation behind this series of articles, table of contents and laid out few definitions. Today we'll see how you create a mock and setup few basic expectations.

This series is inspired by recent post by Roy Osherove (and its comments) where he asks readers what isolation framework should be featured in second edition of the Art of Unit Testing (by featured I mean used in code samples). Few commenters agreed that some of the frameworks differ in syntax only and I thought it would be educational to check how far those differences go.

Ever attempted to mock any of the following:

• private method (Moq)?
• static method (RhinoMocks)?
• extension method (FakeItEasy)?

What all those points have in common? They share similar problem - you cannot do that. Why is that so? To explain why such limitation is present on all of the most popular mocking frameworks, first we need to understand how exactly they work.