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.
In the previous post of this series, we covered two ideas to avoid the NullReferenceException: we should check for null before accessing the members of an object and check the input parameters of our methods.
Let’s see some new C# operators to simplify null checking and a new feature to better signal possible null references.
1. C# Nullable Operators
C# has introduced new operators to simplify our null checks: ?., ??, and ??=. These operators don’t prevent us from having null in the first place, but they help us to easily write our null checks.
Without Nullable Operators
Let’s start with an example and refactor it to use these new operators.
If you have worked with the old ASP.NET framework, you might have done something like that. If not, don’t worry. We’re only accessing a property down in a property chain, but any of those properties could be null.
Notice that to defend against null, we checked if every property was null to “fail fast” and use a default value.
With Nullable Operators
Now, let’s use the new nullable operators instead,
With the null-conditional operator (?.), we access the property or method of an object only if the object isn’t null. Otherwise, the entire expression evaluates to null. For our example, we retrieve ApplicationPath only if Request isn’t null and Current isn’t null, and HttpContext isn’t null.
Then, with the null-coalescing operator (??), we evaluate an alternative expression if the one on the left of the ?? operator isn’t null. For our example, if any of the properties in the chain to retrieve ApplicationPath is null, the whole expression is null, and the path variable gets assigned to the default string.
With the null-coalescing assignment operator (??=), we assign a new value to a variable only if it’s null. We could also write our example like this,
varpath=HttpContext.Current?.Request?.ApplicationPath;path??="/some-default-path-here";// ^^^^//// The same as//if (path == null)//{// path = "/some-default-path-here"; //}
Notice how we refactored our original example to only two lines of code with these three new operators. Again we could still have null values. These nullable operators make our lives easier by simplifying our null checks.
To solve the NullReferenceException, we should check for null. We got that! But the thing is knowing when we should do it or not. That’s precisely what C# 8.0 solves with Nullable References.
With C# 8.0, all reference variables are non-nullable by default. Accessing the member of nullable references results in compiler warnings or errors.
This is a breaking change. Therefore we need to turn on this feature at the project level in our csproj files. Like these,
<ProjectSdk="Microsoft.NET.Sdk"><PropertyGroup><OutputType>Exe</OutputType><TargetFramework>net6.0</TargetFramework><!-- ^^^^^^ --><!-- We could use netcoreapp3.1|net5.0|net6.0|.net7.0 too --><ImplicitUsings>enable</ImplicitUsings><Nullable>enable</Nullable><!-- ^^^^^^ --><!-- We could use enable|disable|warning too --><WarningsAsErrors>nullable</WarningsAsErrors><!-- ^^^^^^^^ --><!-- We can take the extreme route --></PropertyGroup></Project>
To use Nullable References, we need to target .NET Core 3 and upward. And inside the Nullable node in our csproj files, we could use: enable, disable, or warning. Even, we can take the extreme route and consider all nullable warnings as compilation errors.
With Nullable References On
Let’s see what our motivating example looks like with Nullable References turned on,
stringpath=null;// ^^^^// CS8600: Converting null literal or possible null value to non-nullable typeif(HttpContext.Current==null||HttpContext.Current.Request==null||HttpContext.Current.Request.ApplicationPath==null){path="/some-default-path-here";}else{path=HttpContext.Current.Request.ApplicationPath;}// This isn't the real HttpContext class...// We're writing some dummy declarations to prove a pointpublicclassHttpContext{publicstaticHttpContextCurrent;// ^^^^^^^^// CS8618: Non-nullable field 'Current' must contain// a non-nullable value when exiting constructorpublicHttpContext()// ^^^^^^^^^^^// CS8618: Non-nullable field 'Current' must contain// a non-nullable value when exiting constructor{}publicRequestRequest{get;set;}}publicrecordRequest(stringApplicationPath);
Notice we have a warning when initializing path to null. And another one in the declaration of our HttpContext class if we don’t initialize any non-nullable fields. That’s not the real HttpContext by the way but bear with me. Also, we don’t need to check for null when retrieving the ApplicationPath since all our references aren’t nullable by definition.
To declare a variable that can be null, we need to add to its type declaration a ?. In the same way, we have always declared nullable primitive types like int?.
Without Null Checks
Let’s change our example to have nullable references and no null checks,
// Notice the ? symbol here// vvvstring?path=HttpContext.Current.Request.ApplicationPath;// ^^^^^^^^^^^// CS8602: Deference of a possibly null value// This isn't the real HttpContext class...// We're writing some dummy declarations to prove a pointpublicclassHttpContext{publicstaticHttpContext?Current;// ^^^// Notice the ? symbol herepublicHttpContext()// ^^^// No more warnings here{}publicRequestRequest{get;set;}}publicrecordRequest(string?ApplicationPath);
Notice this time, when declaring the variable path, we have a warning because we’re accessing the Current property, which might be null. Also, notice we changed, inside the HttpContext class, the Current property to have the HttpContext? type (with a ? at the end of the type).
Now with Nullable References, we have a way of telling when we should check for null by looking at the signature of our methods.
Voilà! Those are the new C# operators to simplify our null checks. We said “new” operators, but we have had them since C# 6.0. And that’s how we can tell if our references can be null or not using Nullable References.
We have these nullable operators available even if we’re using the old .NET Framework. But, to use Nullable References, we should upgrade at least to .NET Core 3.0.
