Testing on Artur Rios Lab

How I Develop APIs

Wed, 21 Oct 2026 19:30:00 +0000

Every backend I build is an ASP.NET Core API, and they all look alike on purpose. When the structure is the same everywhere, I never have to remember where a thing lives, a new feature is a list of files to add rather than a design decision, and a test that fails points at one small piece of code.

This page describes that shape, using Heimdall as the example throughout. Heimdall is my identity management API: people, applications, logins, two-factor authentication and permissions, for several client systems at once, each in its own scope. It is the largest API I have, so every pattern here has been tested against a real use case rather than a toy one. All code on this page is taken from it, trimmed only where noted.

How I Start a Project From Scratch

Wed, 21 Oct 2026 17:30:00 +0000

Every project on this site starts the same way. Not with code, but with a document, because the cheapest place to find a mistake is in a sentence, before anything has been built on top of it. This is the roadmap I follow, from the first idea to a system that is ready to use:

Create a brainstorm document for the project, with ideas about its nature, its implementation and the technologies to use.
Refine the brainstorm into four initial documents: Project Overview, Technology Stack, Workflow and Business Rules.
Formalise them into a Vision Document, a System Requirements Document and a Use Case Specification Document.
Review the documents, improve them, and review them again until they match what the project is meant to be.
Create GitHub issues for the initial scaffold and infrastructure.
Create a GitHub issue for each use case, linked to a GitHub Project and to an MVP milestone.
Implement the initial scaffold and infrastructure.
Implement one use case after another, including unit and functional tests.
For each use case, run the tests and fix until all of them pass, and only then move on to the next one.
Run a final test of the full functionality and fix any issue found, repeating until the system is ready.

The ten steps fall into four phases:

The .NET Libraries I Reach For

Wed, 21 Oct 2026 13:20:00 +0000

Every new .NET project starts with the same handful of decisions. How will I test it? Where does fake data come from? How do I validate input, survive a flaky dependency, export a spreadsheet, run something every night? The base class library answers some of these. For the rest, I have settled on a short list of NuGet packages that I add almost without thinking.

This page is that list, with the reasoning written down. For each library I explain what it is for, why I use it, show a small example and say when I would pick something else. A recommendation is only as good as what it leaves out, so I also flag what I would want to know before adding a dependency: licence, maintenance, breaking changes, and in two cases events that every user of the library should know about.

Test Coverage in .NET: What It Measures and How to Collect It

Wed, 21 Oct 2026 13:10:00 +0000

A pull request comes back with a comment: “coverage dropped from 84% to 81%”. What does the number mean? Which 3% went missing, and does it matter? Coverage is one of the few test metrics that every .NET tool can produce for free, and one of the easiest to misread. It is very good at answering which code did no test run? and close to useless at answering are the tests any good?

What Is a Unit Test? Where Unit Testing Came From and How to Write Good Ones

Tue, 20 Oct 2026 22:30:00 +0000

You change one line in a pricing function and want to know whether anything broke. You could start the whole application, log in, fill a cart and look at the total, for every kind of cart you can think of. Or you could run a few hundred small programs that each call the pricing function with one input and check the answer, and know in under a second. Those small programs are unit tests, and the second way of working is one of the biggest changes in how software has been written in the last thirty years: from testing as a phase at the end of a project, done by someone else, to testing as something every programmer does every few minutes.