Integration Tests in ASP.NET Core API
Automated testing is an important part of modern software production as it ensures higher quality and faster delivery, and on the same time it makes testing more affordable. Integration tests, sitting just between Unit Tests and E2E tests, improve test coverage and ensure proper communication between units. In this post, we will explore the possibilities of integration testing of ASP.NET Core by using xUnit to create a test for multiple endpoints.
Using LiteDB in an ASP.NET Core API
LiteDB is serverless MongoDB-like database delivered in a single DLL (less than 350kb) fully written in .NET C# managed code (compatible with .NET 3.5, 4.x, NETStandard 1.3 and 2.0). It is ideal for mobile apps or for small desktop/web apps, and its API is very similar to MongoDB C# Official Driver.
In this post, we will see how to use LiteDB as a storage for an ASP.NET API and do simple CRUD operations with it.
Action results in ASP.NET CORE APIs
ASP.NET Core supports creating RESTful services, also known as web APIs. To handle requests, a web API uses controllers with actions (in essence methods) that return an
ActionResult. Since an
ActionResult can be almost anything (it’s like returning an object from your methods), it makes sense to know how to use it and when to choose to return a specific type instead.
Unit testing a custom middleware in ASP.NET Core API
Middlewares are a fundamental part of any ASP.NET Core application, introduced from day one. They are executed in the order they are added on every request, and could be considered similar to the
HttpModules of the classic ASP.NET. Since middlewares can execute code before or after calling the next in the pipeline, they are considered ideal for a ton of various application features, including exception handling, logging, authentication etc.
Error handling in ASP.NET Core Web API
We all know the traditional try-catch blocks and -used correctly- there is of course nothing wrong with them! But even though all is good with that, ASP.NET Core has an even better way of doing things, two ways actually, that can make our code cleaner and easier to read! By following the “Middleware” approach, we extract all our custom exception handling code from within the actions and centralizing it in one place thus, cleaner code!
In this post we will explore these three cases, and starting from the simple try-catch block we will refactor towards a custom error handling middleware.
IdentityServer4, ASP.NET Core API and a client with username/password
This is an end-to-end guide on how to quickly setup IdentityServer4, use it in your ASP.NET Core API for authentication, and finally login to your API from a client by asking a user for their username and password. It is divided in three parts that describe respectively the configuration of each one of the following three systems:
Writing a custom OutputFormatter to return an Excel (.xlsx) from an action in ASP.NET Core API
As most of us, I already know my next week work schedule. It includes writing some actions in respond to a requirement for excel exports. It’s nothing new and its’s relatively easy with libraries like NPOI: you just create your excel on the fly and return a FileResult.