I often ask candidates to define a good unit test. This is the starting point of a conversation around testing strategies and delivering value. Over the years I’ve heard opinions ranging from the 100% coverage, passing by testing is for testers, all the way to we don't do automated testing. If the notion of a good test can be subjective, it is easier to identify a bad test. Bloggers have written about this topic at length but I thought I would try paraphrasing the same content hoping nobody would notice.

I must admit I have written - quite - a few bad tests myself and that’s fine. We all make mistakes, how we handle those mistakes is what help us grow:

• It’s important to understand why the mistake happened and put in place measures to prevent the same mistake from happening again
• Equally we should challenge existing practices, they might be there for a good reason but they might instead be there for a bad reason

This new series is an attempt to improve my WinDbg skills. The concept is to create faulty applications and troubleshoot the issue using WinDbg pretending that I have no prior knowledge of the code.

I’ll be using my WinDbg guide as I can never remember the commands! I’m hoping than through those challenges I’ll get to improve the guide. Today’s exercise is inspired by the excellent blog post Pinpointing a Static GC Root with SOS. The post only contains a few commands but I must admit that it took me hours to achieve the same result.

Elastic Beanstalk is a great platform, it offers both a Web tier and a Worker tier. I recently wrote about Simple Routing one of my library that allows you to route a SQS message to a specific endpoint on the Worker.

While Beanstalk works great once it’s deployed to AWS there is no easy way to run it locally. As soon as you want to execute an end-to-end flow involving both the Web and the Worker you need to manually POST requests to the Worker using Postman which is cumbersome and error-prone.

As it core all the SQS daemon does is dequeue messages from a SQS queue and POST it to a specified endpoint. With this goal in mind I wrote Beanstalk Seeder.

Even though the class HttpClient implements IDisposable it is supposed to be used as a singleton as stated in the API reference:

HttpClient is intended to be instantiated once and re-used throughout the life of an application. Instantiating an HttpClient class for every request will exhaust the number of sockets available under heavy loads. This will result in SocketException errors.

The accepted best practice is to have one HttpClient per HTTP endpoint you’re interacting with. This will not only yield better performance it also allows to encapsulate endpoint specific logic (such as setting headers).

Now the question is: how do you configure your IoC container to resolve the expected HttpClient instance? This used to require a cumbersome registration but .NET Core 2.1 will ship with the HttpClientFactory making our life much easier.