Gherkin scenarios in Specification by Example are used to describe the functional requirements of your software. They should be readable for the team and also for the business that uses the software. Technical ids don’t have a place here. They’re usually included in scenarios for test automation purposes but make the them harder to read. So, what to do when your code requires a technical id?
In this post I show how I install and update the .NET Core Runtime & Hosting Bundle on Windows servers using Azure Pipelines. Making patching .NET Core a trivial matter.
I’ve recently created a new NuGet package called FluentAssertions.ArgumentMatchers.Moq that I published on nuget.org. In order to make the process of creating and publishing this package as smooth and simple as possible, I’ve created a multi-stage YAML pipeline in Azure DevOps.
I still come across a lot of automated tests with many lines of code just to create an object. Even when most data is not relevant for the scenario being tested.
