Testing anti-patterns #1
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
WinDbg #1 - The static root
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.Continue reading
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
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.
Singleton HTTP Client
Even though the
IDisposable it is supposed to be used as a singleton as stated in the API reference:
HttpClientis intended to be instantiated once and re-used throughout the life of an application. Instantiating an
HttpClientclass for every request will exhaust the number of sockets available under heavy loads. This will result in
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.