When it comes to testing, we usually hear that the tests are too slow. While that is a problem, we can also run into unexpected problems if the tests run too fast.
We had this line in one of our tests that checks with Fluent Assertions that the newest entry for our order history was written in the last minute:
Last week we run into a strange problem with our integration tests. On some developer machines everything worked fine, while other machines got errors like this one:
System.InvalidOperationException : Cannot resolve scoped service 'my.application.IOrderRepository' from root provider. at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteValidator.ValidateResolution(Type serviceType, IServiceScope scope, IServiceScope rootScope)
If you need an API endpoint that gives you some (static) test data, you can join the search for the most complicated solution. My current favourite in unnecessary complexity is to use MongoDB to serve a handful of JSON objects.
However, if you prefer a much lighter approach and already use .Net, I strongly recommend that you try Web API for this task. It only takes a few lines to get your data in a format that you can access from your application. And if you want to keep going on, you can add more functionality with ease.
Since I wrote about how to migrate from Moq to NSubstitute, we decided to migrate our work projects as well. The migration was much simpler than anticipated and we got some nice benefits along the way.
If we want to test our code, we often need files with the right format. We can create a text file without much effort, but what do we do if we need a specific video format or an audio file in OGG?
Luckily, we are not the only ones with this problem. There are dedicated sites that offers a wide range of file formats that we can use for testing.
I was a happy user of the Moq library for the last 12 years. I liked the simplicity of Moq and how it allowed me to write tests first and then incrementally build the functionality.
Unfortunately, the creator of Moq is currently doing his best to kill the project. As he declared, either his spyware SponsorLink strong-arms enough individual developers into sponsoring him, or he will quit developing Moq. This leaves us in a lose-lose situation and for me it is time to move my private projects to another mocking library.
I played with a few alternatives and finally settled with NSubstitute. It covers all my use cases and offers an even simpler syntax than what I know from Moq.
If I run into tasks that I must repeat countless times, I try to automate them as much as possible. Since we always add the same dependencies to our test projects, we thought it would be a great idea to create a project template that has all the necessary settings already in place. Let us figure out how little effort it takes to create our own project templates for dotnet, Visual Studio and Rider.
The code coverage is an important part of the quality metrics of SonarQube. Unfortunately, SonarQube needs some extra steps to use our code coverage reports from our Azure DevOps pipeline as part of its code analysis.
As in the last posts on code coverage, we again use Coverlet and ReportGenerator as part of our Azure DevOps build pipeline.
Last week we used Coverlet and ReportGenerator to collect code coverage on our development machines. In this post we continue this journey and extend our build pipelines to get a nice coverage report with every continuous integration build.
For .Net 4.8 it was enough to install Visual Studio Enterprise Edition on the build server and check the box for code coverage in the Testing task of Azure DevOps. The build agent then collected the coverage data and published it as part of your builds. Unfortunately, for .Net 6 this no longer works, and we need to go through a lot more steps.
There are a handful projects for code coverage that support .Net "core", but not every project is still under active development. Be careful when you select a coverage tool and make sure that there is still some activity going on.