My articles about automated testing

When working with unit tests in .NET, you might find yourself using the Moq framework to create mock objects. However, there are alternative frameworks like FakeItEasy that offer similar functionalities using a different approach. In this article, we’ll explore how to replace Moq with FakeItEasy, focusing on the following changes:

1. Instantiating a New Mock
2. Setting up / Mocking the response of a method
3. Setting up properties
4. Passing the Mock as a parameter to a class
5. Replacing the Protected method of Moq
6. Verifying method calls

When you create a fake object using FakeItEasy, it allows you to configure the behavior of its methods and properties. By default, not configured calls to these members return default values, for example a method call will return null. This behavior can make your unit-tests perform unexpectedly, since you will be testing only with the returned default value. If you want to enforce stricter behavior during testing, then strict fakes come into play.

When using the Moq framework for mocking your C# classes, you will have do define what dummy value or values a method of the mocked classes returns. For that we use the Setup method and in the Returns method we define the returned value. The question now is, which dummy value to return when your methods return a IReadOnlyCollection collection.

I know this is not a new question; however, if you search online, you will mostly find articles discussing the older .NET Framework. Here is my way of dealing with 400 (BadRequest) and 404 (NotFound) errors using the latest .NET Core 3.0 WebAPI methods.

Some time ago I wrote an article about Moq with some tricks I used while unit testing my code.

In this article you will find some more tips that I found very useful while using the framework.

Moq is probably the most known framework for mocking functionality which is then used in your unit-tests. In this article you can find some of my notes about Moq that I wanted to share with you.

Unit testing existing code can sometimes be challenging, especially when dealing with classes that contain too much functionality. In such cases, the Single Responsibility principle was not in focus.Refactoring the code can be an issue, so you will have to unit-test the class as it is. Additionally, we do not want to “mock” the interface of a class, which would mock all its methods, but the class itself.