Mocking expected behaviour of SQL functions for Unit Testing with SQLite
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'.'
.
Simple website stress tool with C# and Apache HTTP server benchmarking tool
To be honest, I got bored trying to remember all switches and combinations of Apache’s benchmarking tool! Since I use it sort of rarely, I just wrapped it in a convenient -for me at least- app that I can use without having to remember or read anything!
ASP.NET MVC 5 with Razor Kendo UI: Dynamic Grid Creation – Columns, Ordering, Grouping and Paging
The requirements were simple! A grid that will load a whatever query, grouped by whatever columns, with filters enabled, paging and everything. Easy task with ASP.NET Telerik grids but not easy at all with Kendo UI!
Since we can’t have a ViewModel or Model for the grid (we don’t know what columns a whatever query has!), I came up with a rather different ViewModel that holds descriptions for columns, groups etc…:
ASP.NET MVC 5: Custom authentication with OnActionExecuting
Although I prefer the AuthorizeAttribute approach, there is another simpler way with a base Controller and OnActionExecuting:
Let’s assume the following Controller:
ASP.NET MVC 5: Custom AuthorizeAttribute for custom authentication
In a previous post I wrote about how you can should protect your web app from human errors by enforcing authentication by default.
ASP.NET MVC 5: “Authorization” by default for your web app
Securing your MVC app is a tricky business! Although security is a huge topic, one of the problems that you might encounter is that unauthenticated users are allowed by default to execute every action in your web app. This behaviour is potentially unsafe because you have to remember to decorate your actions with the authorize attribute each and every time, and humans are of course prone to errors!