This year, inspired by C# Advent and 24 Pull Requests, I decided to do my own Christmas challenge: my own Advent of Code. I prefer to call it: Advent of Posts. Starting on December 1st, I’m publishing 24 posts, one post per day.
The challenge is to write an article per day in about 2 hours, including proof-reading and banner design. I’ve written some of the post in advance to avoid content pressure.
Do you have fast unit tests? This is how I speeded up a slow test suite from one of my client’s projects by reducing the delay between retry attempts and initializing slow-to-build dependencies only once. There’s a lesson behind this refactoring session.
Make sure to have a fast test suite that every developer could run after every code change. The slower the tests, the less frequently they’re run.
I learned to have some metrics before rushing to optimize anything. I learned it while trying to optimize a slow room searching feature. These are the tests and their execution time before any changes:
Slow tests
Of course, I blurred some names for obvious reasons. I focused on two projects: Api.Tests (3.3 min) and ReservationQueue.Tests (18.9 sec).
I had a slower test project, Data.Tests. It contained integration tests using a real database. Probably those tests could benefit from simple test values. But I didn’t want to tune stored procedures or queries.
This is what I found and did to speed up this test suite.
Step 1: Reduce delays between retries
Inside the Api.Tests, I found tests for services with a retry mechanism. And, inside the unit tests, I had to wait more than three seconds between every retry attempt. C’mon, these are unit tests! Nobody needs or wants to wait between retries here.
My first solution was to reduce the delay between retry attempts to zero.
Set retryWaitSecond = 0
Some tests built retry policies manually and passed them to services. I only needed to pass 0 as a delay. Like this,
Some other tests used an EventHandler base class. After running a command handler wrapped in a database transaction, we needed to call other internal microservices. We used event handlers for that. This is the EventHandlerBase,
publicabstractclassEventHandlerBase<T>:IEventHandler<T>{protectedRetryOptions_retryOptions;protectedEventHandlerBase(){_retryOptions=newRetryOptions();// ^^^^^// By default, it has:// MaxRetries = 2// RetryDelayInSeconds = 3}publicasyncTaskExecuteAsync(TeventArgs){try{awaitBuildRetryPolicy().ExecuteAsync(async()=>awaitHandleAsync(eventArgs));}catch(Exceptionex){// Sorry, something wrong happened...// Log things here like good citizens of the world...}}privateAsyncPolicyBuildRetryPolicy(){returnPolicy.Handle<HttpRequestException>().WaitAndRetryAsync(_retryOptions.MaxRetries,(retryAttempt)=>TimeSpan.FromSeconds(Math.Pow(_retryOptions.RetryDelayInSeconds,retryAttempt)),// ^^^^^(exception,timeSpan,retryCount,context)=>{// Log things here like good citizens of the world...});}publicvirtualvoidSetRetryOptions(RetryOptionsretryOptions)// ^^^^^{m_retryOptions=retryOptions;}protectedabstractTaskHandleAsync(TeventArgs);}
Notice one thing: the EventHandlerBase didn’t receive a RetryOptions in its constructor. All event handlers had, by default, a 3-second delay. Even the ones inside unit tests. Arrrgggg! And the EventHandlerBase used an exponential backoff. Arrrgggg! That explained why I had those slow tests.
The perfect solution would have been to make all child event handlers receive the right RetryOptions. But it would have required changing the Production code and probably retesting some parts of the app.
Instead, I went through all the builder methods inside tests and passed a RetryOptions without delay. Like this,
Adding a RetryOptions
After removing that delay between retries, the Api.Tests ran faster.
Step 2: Initialize AutoMapper only once
Inside the ReservationQueue.Tests, the other slow test project, I found some tests using AutoMapper. Oh, boy! AutoMapper! I have a love-and-hate relationship with AutoMapper. I shared about AutoMapper in a past Monday Links episode.
Some of the tests inside ReservationQueue.Tests looked like this,
[TestClass]publicclassACoolTestClass{privateclassTestBuilder{publicMock<ISomeService>SomeService{get;set;}=newMock<ISomeService>();privateIMappermapper=null;internalIMapperMapper// ^^^^^{get{if(mapper==null){varservices=newServiceCollection();services.AddMapping();// ^^^^^varprovider=services.BuildServiceProvider();mapper=provider.GetRequiredService<IMapper>();}returnmapper;}}publicServiceToTestBuild(){returnnewServiceToTest(Mapper,SomeService.Object);// ^^^^^}publicTestBuilderSetSomeService(){// Make the fake SomeService instance return some hard-coded values...}}[TestMethod]publicvoidATest(){varbuilder=newTestBuilder().SetSomeService();varservice=builder.Build();service.DoSomething();// Assert something here...}// Imagine more tests that follow the same pattern...}
These tests used a private TestBuilder class to create a service with all its dependencies replaced by fakes. Except for AutoMapper’s IMapper.
To create IMapper, these tests had a property that used the same AddMapping() method used in the Program.cs file. It was an extension method with hundreds and hundreds of type mappings. Like this,
publicstaticIServiceCollectionAddMapping(thisIServiceCollectionservices){varconfiguration=newMapperConfiguration((configExpression)=>{// Literally hundreds of single-type mappings here...// Hundreds and hundreds...});configuration.AssertConfigurationIsValid();services.AddSingleton(configuration.CreateMapper());returnservices;}
Look at the line numbers on the left!
The thing is that every single test created a new instance of the TestBuilder class. And, by extension, an instance of IMapper for every test. And creating an instance of IMapper is expensive. Arrrgggg!
A better solution would have been to use AutoMapper Profiles and only load the profiles needed in each test class. That would have been a long and painful refactoring session.
Use MSTest ClassInitialize attribute
Instead of creating an instance of IMapper when running every test, I did it only once per test class. I used MSTest [ClassInitialize] attribute. It decorates a static method that runs before all the test methods of a class. That was exactly what I needed.
My sample test class using [ClassInitialize] looked like this,
[TestClass]publicclassACoolTestClass{privatestaticIMapperMapper;// ^^^^^[ClassInitialize]// ^^^^^publicstaticvoidTestClassSetup(TestContextcontext)// ^^^^^{varservices=newServiceCollection();services.AddMapping();// ^^^^^varprovider=services.BuildServiceProvider();Mapper=provider.GetRequiredService<IMapper>();}privateclassTestBuilder{publicMock<ISomeService>SomeService{get;set;}=newMock<ISomeService>();// No more IMapper initializations herepublicServiceToTestBuild(){returnnewServiceToTest(Mapper,SomeService.Object);// ^^^^^}publicTestBuilderSetSomeService(){// Return some hardcoded values from ISomeService methods...}}// Same tests as before...}
I needed to replicate this change in other test classes that used AutoMapper.
After reducing the delay between retry attempts and creating IMapper once per test class, these were the final execution times,
Faster tests
That’s under a minute! They used to run in ~3.5 minutes.
Voilà! That’s how I speeded up this test suite. Apart from reducing delays between retry attempts in our tests and initializing AutoMapper once per test class, the lesson to take home is to have a fast test suite. A test suite we can run after every code change. Because the slower the tests, the less frequently we run them. And we want our backs covered by tests all the time.
Let’s continue refactoring some tests for an email component. Last time, we refactored two tests that remove duplicated email addresses before sending an email. This time, let’s refactor two more tests. But these ones check that we change an email status once we receive a “webhook” from a third-party email service. Let’s refactor them.
Here are the tests to refactor
If you missed the last refactoring session, these tests belong to an email component in a Property Management Solution. This component stores all emails before sending them and keeps track of their status changes.
These two tests check we change the recipient status to either “delivered” or “complained.” Of course, the original test suite had more tests. We only need one or two tests to prove a point.
usingMoq;namespaceAcmeCorp.Email.Tests;publicclassUpdateStatusCommandHandlerTests{[Fact]publicasyncTaskHandle_ComplainedStatusOnlyOnOneRecipient_UpdatesStatuses(){varfakeRepository=newMock<IEmailRepository>();varhandler=BuildHandler(fakeRepository);varcommand=BuildCommand(withComplainedStatusOnlyOnCc:true);// ^^^^^awaithandler.Handle(command,CancellationToken.None);fakeRepository.Verify(t=>t.UpdateAsync(It.Is<Email>(d=>d.Recipients[0].LastDeliveryStatus==DeliveryStatus.ReadyToBeSent// ^^^^^&&d.Recipients[1].LastDeliveryStatus==DeliveryStatus.Complained)),// ^^^^^Times.Once());}[Fact]publicasyncTaskHandle_DeliveredStatusToBothRecipients_UpdatesStatuses(){varfakeRepository=newMock<IEmailRepository>();varhandler=BuildHandler(fakeRepository);varcommand=BuildCommand(withDeliveredStatusOnBoth:true);// ^^^^^awaithandler.Handle(command,CancellationToken.None);fakeRepository.Verify(t=>t.UpdateAsync(It.Is<Email>(d=>d.Recipients[0].LastDeliveryStatus==DeliveryStatus.Delivered// ^^^^^&&d.Recipients[1].LastDeliveryStatus==DeliveryStatus.Delivered)),// ^^^^^Times.Once());}privatestaticUpdateStatusCommandHandlerBuildHandler(Mock<IEmailRepository>fakeRepository){fakeRepository.Setup(t=>t.GetByIdAsync(It.IsAny<Guid>())).ReturnsAsync(BuildEmail());returnnewUpdateStatusCommandHandler(fakeRepository.Object);}privatestaticUpdateStatusCommandBuildCommand(boolwithComplainedStatusOnlyOnCc=false,boolwithDeliveredStatusOnBoth=false// Imagine more flags for other combination// of statuses. Like opened, bounced, and clicked)// Imagine building a large object graph here// based on the parameter flags=>newUpdateStatusCommand();privatestaticEmailBuildEmail()=>newEmail("A Subject","A Body",new[]{Recipient.To("to@email.com"),Recipient.Cc("cc@email.com")});}
I slightly changed some test and method names. But those are some of the real tests I had to refactor.
What’s wrong with those tests? Did you notice it?
These tests use Moq to create a fake for the IEmailRepository and the BuildHandler() and BuildCommand() factory methods to reduce the noise and keep our test simple.
Let’s take a look at the first test. Inside the Verify() method, why is the Recipient[1] the one expected to have Complained status? what if we change the order of recipients?
Based on the scenario in the test name, “complained status only on one recipient”, and the withComplainedStatusOnlyOnCc parameter passed to BuildCommand(), we might think Recipient[1] is the email’s cc address. But, the test hides the order of recipients. We would have to inspect the BuildHandler() method to see the email injected into the handler and check the order of recipients.
In the second test, since we expect all recipients to have the same status, we don’t care much about the order of recipients.
We shouldn’t hide anything in builders or helpers and later use those hidden assumptions in other parts of our tests. That makes our tests difficult to follow. And we shouldn’t make our readers decode our tests.
Explicit is better than implicit
Let’s rewrite our tests to avoid passing flags like withComplainedStatusOnlyOnCc and withDeliveredStatusOnBoth, and verifying on a hidden recipient order. Instead of passing flags for every possible combination of status to BuildCommand(), let’s create one object mother per status explicitly passing the email addresses we want.
First, instead of creating a fake EmailRepository with a hidden email object, we wrote a With() method. And to make things more readable, we renamed BuilEmail() to EmailFor() and passed the destinations explicitly to it. We can read it like mock.With(EmailFor(anAddress)).
Next, instead of using a single BuildCommand() with a flag for every combination of statuses, we created one object mother per status: ComplaintFrom() and DeliveredTo(). Again, we passed the email addresses we expected to have either complained or delivered statuses.
Lastly, for our Assert part, we created two custom Verify methods: VerifyUpdatedStatusFor() and VerifyUpdatedStatusForAll(). In the first test, we passed to VerifyUpdatedStatusFor() an array of tuples with the email address and its expected status.
Voilà! That was another refactoring session. When we write unit tests, we should strive for a balance between implicit code to reduce the noise in our tests and explicit code to make things easier to follow.
In the original version of these tests, we hid the order of recipients when building emails. But then we relied on that order when writing assertions. Let’s not be like magicians pulling code we had hidden somewhere else.
Also, let’s use extension methods and object mothers like With(), EmailFor(), and DeliveredTo() to create a small “language” in our tests, striving for readability. The next person writing tests will copy the existing ones. That will make his life easier.
For this Monday Links, I’d like to share five reads about interviewing, motivation, and career. These are five articles I found interesting in the past month or two.
Programming Interviews Turn Normal People into A-Holes
This is a good perspective on the hiring process. But from the perspective of someone who was the hiring manager. Two things I like about this one: “Never ask for anything that can be googled,” and “Decide beforehand what questions you will ask because I find that not given any instructions, people will resort to asking trivia or whatever sh*t library they are working on.”
I’ve been in those interviews that feel like an interrogatory. The only thing missing was a table in the middle of a dark room with a two-way mirror. Like in spy movies. Arrrggg!
From this article, a message for bosses: “…(speaking about salaries, dual monitors, ping pong tables) These things are ephemeral, though. If you don’t have him working on the core functionality of your product, with tons of users, and an endless supply of difficult problems, all of the games of ping pong in the world won’t help.”
How to Spot Signs of Burnout Culture Before You Accept a Job
We only have one chance of giving a first impression. Often the first impression we have about one company is the job listing itself. This post shows some clues to read between the lines to detect toxic culture from companies.
I ran from companies with “work under pressure” or “fast pace changing environment” anywhere in the job description. Often that screams: “We don’t know what we’re doing, but we’re already late.” Arrgggg!
I read this one with a bit of skepticism. I was expecting: sprint velocity, planned story points, etc. But I found some interesting metrics, like _five is the number of comments on a document before turning it into a meeting” and “one is the number of times to reverse a resignation.”
Voilà! Another Monday Links. Have you ever found those interrogatories? Sorry, I meant interviews. Do your company track sprint velocity and story points? What metrics do they track instead? Until next Monday Links.
So far in this series about NullReferenceException, we have used nullable operators and C# 8.0 Nullable References to avoid null and learned about the Option type as an alternative to null. Let’s see how to design our classes to avoid null when representing optional values.
Instead of writing a large class with methods that expect some nullable properties to be not null at some point, we’re better off using separate classes to avoid dealing with null and getting NullReferenceException.
Multiple state in the same object
Often we keep all possible combinations of properties of an object in a single class.
For example, on an e-commerce site, we create a User class with a name, password, and credit card. But since we don’t need the credit card details to create new users, we declare the CreditCard property as nullable.
Let’s write a class to represent either regular or premium users. We should only store credit card details for premium users to charge a monthly subscription.
publicrecordUser(Emailemail,SaltedPasswordpassword){publicCreditCard?CreditCard{get;internalset;}// ^^^// Only for Premium users. We declare it nullablepublicvoidBecomePremium(CreditCardcreditCard){// Imagine we sent an email and validate credit card// details, etc//// Beep, beep, boop}publicvoidChargeMonthlySubscription(){// CreditCard might be null here.//// Nothing is preventing us from calling it// for regular usersCreditCard.Pay();// ^^^^^// Boooom, NullReferenceException}}
Notice that the CreditCard property only has value for premium users. We expect it to be null for regular users. And nothing is preventing us from calling ChargeMonthlySubscription() with regular users (when CreditCard is null). We have a potential source of NullReferenceException.
We ended up with a class with nullable properties and methods that only should be called when some of those properties aren’t null.
Inside ChargeMonthlySubscription(), we could add some null checks before using the CreditCard property. But, if we have other methods that need other properties not to be null, our code will get bloated with null checks all over the place.
Instead of checking for null inside ChargeMonthlySubscription(), let’s create two separate classes to represent regular and premiums users.
publicrecordRegularUser(EmailEmail,SaltedPasswordPassword){// No nullable CreditCard anymorepublicPremiumUserBecomePremium(CreditCardcreditCard){// Imagine we sent an email and validate credit card// details, etcreturnnewPremiumUser(Email,Password,CreditCard);}}publicrecordPremiumUser(EmailEmail,SaltedPasswordPassword,CreditCardCreditCard){// Do stuff of Premium Users...publicvoidChargeMonthlySubscription(){// CreditCard is not null here.CreditCard.Pay();}}
Notice we wrote two separate classes: RegularUser and PremiumUser. We don’t have methods that should be called only when some optional properties have value. And we don’t need to check for null anymore. For premium users, we’re sure we have their credit card details. We eliminated a possible source of NullReferenceException.
We’re better off writing separate classes than writing a single large class with nullable properties that only have values at some point.
I learned about this technique after reading Domain Model Made Functional. The book uses the mantra: “Make illegal state unrepresentable.” In our example, the illegal state is the CreditCard being null for regular users. We made it unrepresentable by writing two classes.
Voilà! This is another technique to prevent null and NullReferenceException by avoiding classes that only use some optional state at some point of the object lifecycle. We should split all possible combinations of the optional state into separate classes. Put separate state in separate objects.
If you want to practice the techniques and principles from this series with interactive coding listings and exercises, check my course Mastering NullReferenceException Prevention in C# on Educative. It covers all you need to know to prevent this exception in the first place.
In the previous post of this series, we covered three C# operators to simplify null checks and C# 8.0 Nullable References to signal when things can be null. In this post, let’s learn a more “functional” approach to removing null and how to use it to avoid null when working with LINQ XOrDefault methods.
1. Use Option: A More Functional Approach to Nulls
Functional languages like F# or Haskell use a different approach for null and optional values. Instead of null, they use an Option or Maybe type.
With the Option type, we have a “box” that might have a value or not. It’s the same concept of nullable ints, for example. I bet you have already used them. Let’s see an example,
int?maybeAnInt=null;varhasValue=maybeAnInt.HasValue;// falsevardangerousInt=maybeAnInt.Value;// ^^^^^// Nullable object must have a value.varsafeInt=maybeAnInt.GetValueOrDefault();// 0
With nullable ints, we have variable that either holds an interger or null. They have the HasValue and Value properties, and the GetValueOrDefault() method to access their inner value.
We can extend the concept of a box with possibly a value to reference types with the Option type. We can wrap our reference types like Option<int> or Option<Movie>.
We created two optional ints: someInt and none. Then, we used Map() to double their values. Then, to retrieve the value of each optional, we used ValueOr() with a default value.
For someInt, Map() returned another optional with the double of 42 and ValueOr() returned the same result. And for none, Map() returned None and ValueOr() returned -1.
How to Flatten Nested Options
Now, let’s rewrite the HttpContext example from previous posts,
Notice that instead of appending ? to type declarations like what we did with in the past post when we covered C# 8.0 Nullable References, we wrapped them around Option.
This time, Current is a box with Request as another box inside. And Request has the ApplicationPath as another box.
Now, let’s retrieve the ApplicationPath,
varpath=HttpContext.Current.FlatMap(current=>current.Request)// ^^^^^.FlatMap(request=>request.ApplicationPath)// ^^^^^.ValueOr("/some-default-path-here");// ^^^^// Or//.Match((path) => path , () => "/some-default-path-here");// This isn't the real HttpContext class...// We're writing some dummy declarations to prove a pointpublicclassHttpContext{publicstaticOption<HttpContext>Current;publicHttpContext(){}publicOption<Request>Request{get;set;}}publicrecordRequest(Option<string>ApplicationPath);
To get the ApplicationPath value, we had to open all boxes that contain it. For that, we used the FlatMap() method. It grabs the value in the box, transforms it, and returns another box. With FlatMap(), we can flatten two nested boxes.
Option's FlatMap to flatten nested options
Notice we didn’t do any transformation with FlatMap(). We only retrieved the inner value of Option, which was already another Option.
This is how we read ApplicationPath:
With FlatMap(), we opened the Current box and grabbed the Request box in it.
Then, we used FlatMap() again to open Request and grab the ApplicationPath.
Finally, with ValueOr(), we took out the value inside ApplicationPath if it had any. Otherwise, if the ApplicationPath was empty, it returned a default value of our choice.
“This is the way!” Sorry, this is the “functional” way! We can think of nullable ints like ints being wrapped around a Nullable box with more compact syntax and some helper methods.
2. Option and LINQ XOrDefault methods
Another source of NullReferenceException is when we don’t check the result of the FirstOrDefault, LastOrDefault, and SingleOrDefault methods. These methods return null when the source collection has reference types, and there are no matching elements. In fact, this is one of the most common mistakes when working with LINQ.
There are some alternatives to prevent the NullReferenceException when working with XOrDefault methods.
But, let’s combine the XOrDefault methods with the Option type. We can make the XOrDefault methods return an Option<T> instead of null.
The Optional library has FirstOrNone(), LastOrNone() and SingleOrNone() instead of the usual XOrDefault methods.
This time, let’s use FirstOrNone() instead of FirstOrDefault(),
usingOptional.Collections;// ^^^^^varmovies=newList<Movie>{newMovie("Shrek",2001,3.95f),newMovie("Inside Out",2015,4.1f),newMovie("Ratatouille",2007,4f),newMovie("Toy Story",1995,4.1f),newMovie("Cloudy with a Chance of Meatballs",2009,3.75f)};vartheBestOfAll=newMovie("My Neighbor Totoro",1988,5);// With .NET FirstOrDefault()vartheBest=movies.FirstOrDefault(movie=>movie.Rating==5.0,theBestOfAll);// ^^^^^// With Optional's FirstOrNone()vartheBestAgain=movies.FirstOrNone(movie=>movie.Rating==5.0)// ^^^^^.ValueOr(theBestOfAll);// ^^^^^Console.WriteLine(theBestAgain.Name);recordMovie(stringName,intReleaseYear,floatRating);
By using the XOrNone methods, we’re forced to check if they return something before trying to use their result.
Voilà! That’s the functional way of doing null, with the Option or Maybe type. Here we used the Optional library, but there’s also another library I like: Optuple. It uses the tuple (bool HasValue, T Value) to represent the Some and None subtypes.
Even though we used a library to bring the Option type, we can implement our own Option type and its methods. It’s not that difficult. We need an abstract class with two child classes and a couple of extension methods to make it work.
