My saga on supporting multiple tenants in ASP.NET Core web applications has come to point where tenants can use separate databases. It’s time now to write some tests for data context to make sure it behaves correct in unexpected situations. This post covers unit tests for data context and multi-tenancy.
ASP.NET Core applications can be tested with different testing frameworks and Entity Framework Core makes testing specially easy by removing different technical problems from our way by using in-memory data provider. This blog posts shows how to unit test controllers that use data from Entity Framework Core.
Stored procedures in SQL Server database can be unit tested using Visual Studio database unit tests. It may seem as simple thing to do at first but when you start writing tests then you will find out it’s more complex task to do then expected. In this posting I will introduce database testing with Visual Studio tools.
Here’s my little example about how to use Moq to mock HttpContextBase and it’s members to make controller tests pass. You can use this code when you are not allowed to use open-source or use-on-your-own-risk pieces of software that provide you this kind on initialization using built-in features. Also it is good exercise that introduces you how to solve mocking problems.
Lately I blogged about HttpNotFoundResult and HttpStatusCodeResult action results that come with ASP.NET MVC 3. These results are ideal for controller tests as we don’t have to mess with HttpContext and Response objects anymore. In this posting I will show you how to use HttpNotFoundResult in controller tests to check if errors are given correctly to user.