<a href="https://learn.microsoft.com/en-us/dotnet/aspire/get-started/aspire-overview">.NET Aspire</a> is a newly introduced tool for building distributed solutions that run just as easily locally as they do in the cloud. This video explains how this is a boon for integration testing. <media href="https://www.youtube.com/watch?v=bPIu6PZW41Q" src="https://www.youtube.com/v/bPIu6PZW41Q" width="560px" source="YouTube" caption="End-to-end integration testing with .NET Aspire" author="dotnet / Aaron Powell"> The concept is very nice and seems to greatly simplify building integration tests. Kudos and thanks for the introduction. <img attachment="spaghetti-code.jpg" align="right">Still, my hair was standing on end with some of the "fast and loose" programming in this video, though. I know that people will argue that you have to take a direct path to get it working quickly, but I feel that this degrades programming practice, especially when it comes from an "official" source like Microsoft. There are things like: <ul> Defining the service-initialization code in the tests, then explaining that it's to ensure that it's the "same as that used by the server". You know how else to do that? Use common initialization code in static helper methods (or whatever). Copy/pasting the service-initialization code from test to test Copy/pasting the <c>HTTPClient</c> code Copy/pasting the <c>record</c> definition, as if that won't ever bite you in the butt. Manually adding "usings" (Can't you just get the IDE to do that?) </ul> On top of that, the integration tests could have been a lot simpler than they looked if he'd first explained how to set up some common code. Or, perhaps even better, if he'd taken a couple of minutes afterwards to show how to refactor the common code to helper methods (one of which could even be used in the main application so that the app setup is shared with the tests). If he'd used a few more IDE features to speed up coding, he might even have gotten it all in in the same amount of time.