In the previous blog post I showed how you can unit test with NBuilder and NSubstitute by using a FakeDbSet implementation. The thing is that we do not necessarily have to use a FakeDbSet but can also try and mock the DbSet. Let’s see how we can changes the implementation from last week’s blog post to mock DbSet instead. First thing to note is that a lot of examples for mocking the DbSet using other mocking frameworks such as Moq (such as this one) will demonstrate using DbSet and IQueryable, but it turns out that people using NSubstitute run into all sort of problems with this, as this SO question demonstrates.
Introduction I have mentioned in a previous blog post that I make use of NBuilder and Faker.NET to create test data for my application in development and testing scenarios. I also make use of NBuilder to set up scenarios for testing queries against my DbContext to ensure that the correct data is returned from a query. In this blog post I am going to demonstrate how you can test an ASP.
NSubstitute is my current mocking framework of choice. It contains all the features I require in a mocking framework and is well maintained. I previously mentioned as one of my favourite Nuget packages for .NET and I also showed how you can mock abstract classes. In this blog post I want to talk a little bit about one of the many reasons I like NSubstitute, namely the ability to generate the output of a mocked function call based on the parameters passed into the function.
For the development of One Love, I make use of the wonderful MvvmCross library for implementing the MVVM pattern. This allows me to have a LOT of shared code across all platforms, and also allows me to implement unit testing across all that shared code. There are of course certain things which are platform specific and for that I use the dependency injection which comes standard with MvvmCross. For the unit tests I use a mocking framework to create mocks which are then passed into the constructors of the classes under test.
In the previous blog post we added dependency injection to our project and created our own validation factory which resolves the validators using dependency injection. In this, the final blog post of the series, we will have a look at extending our existing RegisterModelValidator to do some database validation. The database is accessed using the repository pattern which allows us to mock the repository and enable us to unit test the validator without a physical database.
There are a lot of reasons why people suggest you should do Test Driven Development, and even though I was not a total convert right from the beginning, the practice is growing on me. My situation is a bit unique from probably most developers out there, so while I buy into a lot of the common reasons why you should do TDD, there are a few unique advantages I gain from it.