As we moved from .Net Full Framework to .NET 6, we had to use the little hack of creating a AssemblyInfo.cs file and put this content into it to access the internal classes and methods from our test project:
A few months back I reviewed an application. It was sad to see in how little time you could create a mess that is not only hard to work with, but that can only be changed with a lot of effort. In this post we focus on one tiny little detail that can help you as a warning sign early on: having test code directly in the production code.
Whenever we have a method that accepts a list as a parameter, we should test these 5 cases to see if the method handles the input correctly:
Let us take a closer look at each of those inputs and what they can check for us. The list is not my invention, but so far, I was unable to attribute it correctly. If you know who the source was, please let me know.
After spending the last four months diving into performance testing and hunting down memory leaks, this series comes to an end. Let’s take a moment to reflect on the key insights and explore some ideas you can try on your own.
When we talk about performance tests, we usually do it with the goal of making our applications faster. However, we can also focus on the reduction of resources we need to deliver the same performance. If we do not want to blindly meddle with our infrastructure, we need to run our performance tests to guide the optimisation. Let us explore our options.
Last year we moved our applications from .Net 6 to .Net 8. It was much less work that it was to move from .Net 4.8 to .Net 6. The migration itself was straightforward, and we could put our updated application into production without any issues. That was until a week later when we got this strange error:
Application '/LM/W3SVC/11/ROOT' with physical root '...'
hit unexpected managed exception, exception code = '0xe0434352'.
First 30KB characters of captured stdout and stderr logs:
Out of memory.
While it is possible to use WinDbg to dive through your memory dump, it takes a lot of knowledge to do so. A much simpler approach is to use a commercial tool like dotMemory from JetBrains. This tool has a graphical interface that allows us to click through the dump and explore what objects lay around.
The dotnet-dump tool is a great help to create dump files. But even with an administrator account you can sometimes run into this error:
Another problem we may uncover with performance testing is a memory leak. Those nasty problems hide well inside our application, and they may only show up when our application runs for weeks. How can we force them out in the open without waiting for a month?
Last week we used BenchmarkDotNet to compare our improved method against the original one. Since it was faster, we changed the application to use the new code. The final part to close the loop, as my friend Daniel Marbach says, is now to measure the whole application once more to make sure that we indeed get a performance boost.