The art of simplicity

Posts

Making a header parameter required in ASP.NET Core

Yesterday I talked about a breaking change I had inside my ASP.NET Core web api that caused my application to fail. I had a header parameter that was optional but became required after changing the nullability of my project to enabled . My hope was that this would be visible in the OpenAPI metadata for my OpenAPI. Unfortunately, the generated metadata always looked like this: So both this code: and this code: return exactly the same metadata. The lack of a required property marks this header as optional, which doesn't reflect the actual behavior of the application after enabling nullability. I decided to investigate this a little further and found out that it is possible to emit the correct metadata by explicitly adding a [Required] attribute to the parameter: After adding this attribute the metadata was updated correctly. It’s unfortunate that ASP.NET Core doesn’t do this by default as it is aware of the possible nullability of the provided parameters.

API contracts and nullability in ASP.NET Core

Although it is not the first time that I stumble over the nullability feature and breaking changes, this one still caught me by surprise. Let me first explain the context; I have an application built in ASP.NET Core with the nullability feature still disabled. As I had to make some changes to the API, I though it was a good timing to enable the nullability feature to help me avoid nullreference exceptions. As always I started by updating the application to enable the nullability feature. Therefore set the nullable value to enabled inside the csproj file: After enabling the feature, our integration tests started to fail. Here is the specific error message that got returned: In our API we have the option to pass an optional(!) X-Environment header parameter. We use this attribute to avoid that the API is accidently called from our development or test environment. In our original API implementation this attribute is optional; in case the attribute is ommitted we don’t do the en...

Repeating a test multiple times in C#

In JUnit you have the @RepeatedTest annotation. This annotation allows you to run a single test method multiple times with different execution contexts. Unlike simply calling a method in a loop, each repetition is treated as a separate test execution with its own lifecycle. Although it can be useful to discover and investigate race conditions, I never had a good reason to start using this kind of functionality. But with the introduction of AI workloads inside my applications, times have changed. As AI output is less deterministic, it now starts to make sense to run the same test multiple times as the AI output could differ from test run to test run. Let me show you how to do this using NUnit and XUnit... NUnit: Built-in Repeat Attribute NUnit provides the most elegant solution with its built-in [Repeat] attribute: XUnit: Using Theory and Custom Attributes XUnit doesn't provide an out-of-the-box equivalent to the @RepeatedTest annotation but you can build your own ...

Improve your GitHub Copilot prompts with the Prompt Boost extension

If you are new to GitHub Copilot or other AI coding assistants, it can be a challenge to get good results as you are still learning on how to write good prompts. What if there was a way to automatically transform your basic prompts into comprehensive, context-rich instructions that consistently produce better results? Enter Prompt Boost , a VS Code extension that bridges the gap between what you quickly type and what AI models actually need to generate high-quality, relevant code. What is Prompt Boost? Prompt Boost is a VS Code extension created by Chris Dias that enhances your prompts by adding relevant technical context, best practices, and specific requirements. Instead of sending bare-bones requests to GitHub Copilot, it helps you create detailed instructions that lead to more accurate and useful responses. The extension transforms your basic prompts into comprehensive specifications. Here's a real example of the transformation: Before (Basic prompt): Create a new l...

Compiler error ASPIRE007 after upgrading Aspire

After upgrading the .NET Aspire NuGet packages to the latest version on one of my projects, I started to get the following compiler error: 'Project' requires a reference to "Aspire.AppHost.Sdk" with version "9.0.0" or greater to work correctly. Please add the following line after the Project declaration <Sdk Name="Aspire.AppHost.Sdk" Version="9.0.0" /> . The error message is self explanatory and clearly defines how we could fix this. Add the Sdk reference to your csproj file to get rid of this compiler error: The strange thing was that after applying the upgrade on one branch, I also started to get the same compiler error on other branches although the Aspire NuGet were not (yet) upgraded on these branches. Bizar! More information Compiler Error ASPIRE007 - .NET Aspire | Microsoft Learn

Property based testing - Updating FsCheck to version 3.x

f you have never heard about Property based testing, I would recommend to check my blog series about it first. But if you are too lazy to go through all these posts, here is a short definition: Property-based testing is a powerful testing methodology used in software development to verify that a system behaves correctly across a wide range of inputs. Instead of writing individual test cases with specific inputs and expected outputs, property-based testing defines properties —general rules that should always hold true for a given system. It serves as an alternative to example based testing where we focus on a set of example cases to validate the behavior of our code. There are a lot of libraries out there that help you write Property Based Tests. In .NET I mainly use FSCheck and CSCheck . As I’m doing more and more Python, I also start using Property Based Tests there through Hypothesis . In this post I’ll focus on FSCheck and how to update to the latest version as some breakin...