The Task Parallel Library contains a very interesting set of dataflow components that for some reason they didn’t get the attention they deserve. This set is called TPL Dataflow Library and in few words, it is a robust in-process actor library that worth spending some time learning it! In this post, we will learn how to use it for concurrency testing.
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.
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.
Entity Framework Core allows you to drop down to raw SQL queries when working with a relational database. This can be
useful, because raw SQL queries can return entity types or, starting with EF Core 2.1, query types that are part of
your model, but it could also be a problem when it comes down to Unit Testing.
While unit testing, I came across a method in an SQL repository class that was using a raw SQL query, and along with that, SQL Server’s newid() function. Since the complicated reason behind this decision was out of scope, I had to find a way to unit test that method…
SQLite was -of course- the first approach, but any attempt to actually test the method would nevertheless fail with the exception
Microsoft.Data.Sqlite.SqliteException: 'SQLite Error 1: 'no such function: newid'.'.