I like ASP.NET Core BackgroundServices. I’ve used them in one of my client’s projects to run recurring operations outside the main ASP.NET Core API site. Even for small one-time operations, I’ve run them in the same API site.
There’s one catch. We have to write our own retrying, multi-threading, and reporting mechanism. BackgroundServices are a lightweight alternative to run background tasks.
Lite Hangfire
These days, a coworker came up with the idea to use a “lite” Hangfire to replace ASP.NET Core BackgroundServices. By “lite,” he meant an in-memory, single-thread Hangfire configuration.
Let’s create an ASP.NET Core API site and install these NuGet packages:
To make things cleaner, let’s use extension methods to keep all Hangfire configurations in a single place. Like this,
usingHangfire;usingHangfire.Console;usingHangfire.InMemory;usingRecreatingFilterScenario.Jobs;namespaceLiteHangfire.Extensions;publicstaticclassServiceCollectionExtensions{publicstaticvoidConfigureHangfire(thisIServiceCollectionservices){services.AddHangfire(configuration=>{configuration.UseInMemoryStorage();// ^^^^^// Since we have good memoryconfiguration.UseConsole();// ^^^^^});services.AddHangfireServer(options=>{options.SchedulePollingInterval=TimeSpan.FromSeconds(5);// ^^^^^// For RecurringJobs: Delay between retries.// By default: 15secoptions.WorkerCount=1;// ^^^^^// Number of worker threads.// By default: min(processor count * 5, 20)});GlobalJobFilters.Filters.Add(newAutomaticRetryAttribute{Attempts=1// ^^^^^// Retry count.// By default: 10});}publicstaticvoidConfigureRecurringJobs(thisWebApplicationapp){//var config = app.Services.GetRequiredService<IOptions<MyRecurringJobOptions>>().Value;// ^^^^^^^^^// To read the cron expression from a config fileRecurringJob.AddOrUpdate<ProducerRecurringJob>(ProducerRecurringJob.JobId,x=>x.DoSomethingAsync(),"0/1 * * * *");// ^^^^^^^^^// Every minute. Change it to suit your own needsRecurringJob.Trigger(ProducerRecurringJob.JobId);}}
Notice that we used the UseInMemoryStorage() method to store jobs in memory instead of a database and the UseConsole() to bring color to our logging messages in the Dashboard.
In the previous step, when we registered the Hangfire server, we used these parameters:
SchedulePollingInterval is the time to wait between retries for recurring jobs. By default, it’s 15 seconds. Source
WorkerCount is the number of processing threads. By default, it’s the minimum between five times the processor count and 20. Source
As an aside, I also discovered these settings:
ServerCheckInterval is how often Hangfire checks for “timed out” servers. By default, it’s 5 minutes. Source
ServerTimeout is the time to consider that a server timed out from the last heartbeat. By default, it’s 5 minutes.
Then, we registered the number of retry attempts. By default, Hangfire retries jobs 10 times. Source
3. Write “Producer” and “Consumer” jobs
The next step is to register a recurring job as a “producer.” It looks like this,
usingHangfire;usingHangfire.Console;usingHangfire.Server;namespaceLiteHangfire.Jobs;publicclassProducerRecurringJob{publicconststringJobId=nameof(ProducerRecurringJob);privatereadonlyIBackgroundJobClient_backgroundJobClient;privatereadonlyILogger<ProducerRecurringJob>_logger;publicProducerRecurringJob(IBackgroundJobClientbackgroundJobClient,ILogger<ProducerRecurringJob>logger){_backgroundJobClient=backgroundJobClient;_logger=logger;}publicasyncTaskDoSomethingAsync(){_logger.LogInformation("Running recurring job at {now}",DateTime.UtcNow);// Beep, beep, boop...awaitTask.Delay(1_000);// We could read pending jobs from a database, for exampleforeach(variteminEnumerable.Range(0,5)){_backgroundJobClient.Enqueue<WorkerJob>(x=>x.DoSomeWorkAsync(null));// ^^^^^}}}
Inside this recurring job, we can read pending jobs from a database and enqueue a new worker job for every pending job available.
And a sample worker job that uses Hangfire.Console looks like this,
publicclassWorkerJob{publicasyncTaskDoSomeWorkAsync(PerformContextcontext){context.SetTextColor(ConsoleTextColor.Blue);context.WriteLine("Doing some work at {0}",DateTime.UtcNow);// Beep, beep, boop...awaitTask.Delay(3_000);}}
Notice that we expect a PerformContext as a parameter to change the color of the logging message. When we enqueued the worker jobs, we passed null as context, then Hangfire uses the right instance when running our jobs. Source.
Voilà! That’s how to use a lite Hangfire to replace BackgroundServices without adding too much overhead or a new database to store jobs. With the advantage that Hangfire has recurring jobs, retries, and a Dashboard out of the box.
“Ask questions” is common advice for better code reviews.
At some point, we followed that advice and started using what I call “leading” or “pushy” questions. Questions that only hint a request for a code change.
After working on a remote software team for a couple years, I stopped using “pushy” questions on code reviews. Here’s why it’s a bad idea.
“Pushy” Questions Are Time-Consuming
Let’s imagine we’ve written a method and forgot to check for nulls. Something like this,
If we follow the advice to ask “pushy” questions, we might leave and receive comments like “What if oneParam is null?” or “Could oneParam or anotherParam be null?”
The problem with those types of comments is we can’t tell if they’re genuine questions or actionable items. Is the reviewer asking a clarification question or “pushing” us in a different direction? We can’t tell.
Behind those comments, there’s a hidden change request. How is the code author supposed to know the reviewer is asking for a change?
While working on a remote team, it happened more than once that I had to reach out to reviewers via email or chat to ask them to clarify their intentions behind those comments. But some reviewers were in different time zones or even on the other side of the world. All interactions took about ~24 hours between my initial message and their response.
It was frustrating and time-consuming. Arrrggg!
When it was my turn to be a code reviewer, I chose a different approach: I stopped asking those questions.
Instead of asking “pushy” questions, let’s leave actionable and unambiguous comments that distinguish between questions, to-dos, and nice-to-haves.
Let’s go back to the previous example and leave an unambiguous comment. Like this one: “Is it possible that oneParam could be null? If that’s the case, please let’s add the appropriate null checks. Something like if (oneParam == null) throw ...“
With that comment, it’s clear we’re suggesting a change.
With that convention, we add keywords like “question,” “suggestion” or “nitpick” to clarify the purpose of our comments.
I used it for months in one of my client’s projects and other reviewers started to use it too.
For example, we can turn our previous “pushy” comment into these two depending on our intention:
A clarification question: “question: Is it possible that oneParam could be null?”
A change request: “suggestion (blocking): Let’s add the appropriate null checks if oneParam could be null.”
Now it’s clear we’re referring to two different actions.
Voilà! That’s why I don’t like “pushy” questions in code reviews. Let’s always prefer clear and direct comments without forgetting good manners of course. And let’s remember we review code from people with different experience levels and even non-native speakers of our language.
After this experience, my rule of thumb for better code reviews is to write unambiguous comments and always include a suggestion with each comment.
These days I had to review some code that expected a controller to log the exceptions thrown in a service. This is how that controller looked and what I learned about testing logging messages.
When writing unit tests for logging, assert that actual log messages contain keywords like identifiers or requested values. Don’t assert that actual and expected log messages are exactly the same.
Don’t expect identical log messages
The controller I reviewed looked like this,
usingMicrosoft.AspNetCore.Mvc;usingOnTestingLogMessages.Services;namespaceOnTestingLogMessages.Controllers;[ApiController][Route("[controller]")]publicclassSomethingController:ControllerBase{privatereadonlyIClientService_clientService;privatereadonlyILogger<SomethingController>_logger;publicSomethingController(IClientServiceclientService,ILogger<SomethingController>logger){_clientService=clientService;_logger=logger;}[HttpPost]publicasyncTask<IActionResult>PostAsync(AnyPostRequestrequest){try{// Imagine that this service does something interesting...await_clientService.DoSomethingAsync(request.ClientId);returnOk();}catch(Exceptionexception){_logger.LogError(exception,"Something horribly wrong happened. ClientId: [{clientId}]",request.ClientId);// ^^^^^^^^// Logging things like good citizens of the world...returnBadRequest();}}// Other methods here...}
Nothing fancy. It called an IClientService service and logged the exception thrown by it. Let’s imagine that the controller logged a more helpful message to troubleshoot later. I wrote a funny log message here. Yes, exception filters are a better idea, but bear with me.
To test if the controller logs exceptions, we could write a unit test like this,
usingMicrosoft.Extensions.Logging;usingMoq;usingOnTestingLogMessages.Controllers;usingOnTestingLogMessages.Services;namespaceOnTestingLogMessages.Tests;[TestClass]publicclassSomethingControllerTests{[TestMethod]publicasyncTaskPostAsync_Exception_LogsException(){varclientId=123456;varfakeClientService=newMock<IClientService>();fakeClientService.Setup(t=>t.DoSomethingAsync(clientId)).ThrowsAsync(newException("Expected exception..."));// ^^^^^// 3...2...1...Boom...varfakeLogger=newMock<ILogger<SomethingController>>();varcontroller=newSomethingController(fakeClientService.Object,fakeLogger.Object);// ^^^^^varrequest=newAnyPostRequest(clientId);awaitcontroller.PostAsync(request);varexpected=$"Something horribly wrong happened. ClientId: [{clientId}]";// ^^^^^^^^// We expect exactly the same log message from the PostAsyncfakeLogger.VerifyWasCalled(LogLevel.Error,expected);}}
By the way, .NET 8.0 added a FakeLogger, a logging provider for unit testing, so we don’t have to rely on fakes to test logging.
In our test, we’re expecting the actual log message to be exactly the same as the one from the SomethingController. Can you already spot the duplication? In fact, we’re rebuilding the log message inside our tests. We’re duplicating the logic under test.
Also, let’s notice we used a custom assertion method to make our assertions less verbose. VerifyWasCalled() is an extension method that inspects the Moq instance to check if the actual and expected messages are equal. Here it is,
To make our unit tests more maintainable, let’s check that log messages contain keywords or relevant substrings, like identifiers and values from input requests. Let’s not check if they’re identical to the expected log messages. Any changes in casing, punctuation, spelling or any other minor changes in the message structure will make our tests break.
Let’s rewrite our test,
usingMicrosoft.Extensions.Logging;usingMoq;usingOnTestingLogMessages.Controllers;usingOnTestingLogMessages.Services;namespaceOnTestingLogMessages.Tests;[TestClass]publicclassSomethingControllerTests{[TestMethod]publicasyncTaskPostAsync_Exception_LogsException(){varclientId=123456;varfakeClientService=newMock<IClientService>();fakeClientService.Setup(t=>t.DoSomethingAsync(clientId)).ThrowsAsync(newException("Expected exception..."));// ^^^^^// 3...2...1...Boom...varfakeLogger=newMock<ILogger<SomethingController>>();varcontroller=newSomethingController(fakeClientService.Object,fakeLogger.Object);varrequest=newAnyPostRequest(clientId);awaitcontroller.PostAsync(request);fakeLogger.VerifyMessageContains(LogLevel.Error,clientId.ToString());// ^^^^^^^^// We expect the same log message to only contain the clientId}}
This time, we rolled another extension method, VerifyMessageContains(), removed the expected log message and asserted that the log message only contained only relevant subtrings: the clientId.
Here it is the new VerifyMessageContains(),
publicstaticclassMoqExtensions{publicstaticvoidVerifyMessageContains<T>(thisMock<ILogger<T>>fakeLogger,LogLevellogLevel,paramsstring[]expected){fakeLogger.Verify(x=>x.Log(logLevel,It.IsAny<EventId>(),It.Is<It.IsAnyType>((o,t)=>expected.All(s=>o.ToString().Contains(s,StringComparison.OrdinalIgnoreCase))),// ^^^^^// Checking if the log message contains some keywords, insteadIt.IsAny<Exception>(),It.IsAny<Func<It.IsAnyType,Exception?,string>>()),Times.Once);}}
Voilà! That’s how to make our test that checks logging messages more maintainable. By not rebuilding log messages inside tests and asserting that they contain keywords instead of expecting to be exact matches.
Here we dealt with logging for diagnostic purposes (logging to make troubleshooting easier for developers). But if logging were a business requirement, we should have to make it a separate “concept” in our code. Not in logging statements scatter all over the place. I learned by distinction about logging when reading Unit Testing Principles, Practices, and Patterns.
Want to write readable and maintainable unit tests in C#? Join my course Mastering C# Unit Testing with Real-world Examples on Udemy and learn unit testing best practices while refactoring real unit tests from my past projects. No more tests for a Calculator class.
These days I needed to work with a microservice for one of my clients. In that microservice, instead of validating incoming requests with the built-in model validations or FluentValidation, they use authorization filters. I needed to write some tests for that filter. This is what I learned.
Apart from validating the integrity of the incoming requests, the filter also validated that the referenced object in the request body matched the same “client.”
A weird filter scenario
The filter looked something like this,
usingMicrosoft.AspNetCore.Mvc;usingMicrosoft.AspNetCore.Mvc.Controllers;usingMicrosoft.AspNetCore.Mvc.Filters;usingNewtonsoft.Json;usingMyWeirdFilterScenario.Controllers;namespaceMyWeirdFilterScenario.Filters;publicclassMyAuthorizationFilter:IAsyncAuthorizationFilter{privatereadonlyDictionary<string,Func<AuthorizationFilterContext,Task<bool>>>_validationsPerEndpoint;privatereadonlyIClientRepository_clientRepository;privatereadonlyIOtherEntityRepository_otherEntityRepository;publicMyAuthorizationFilter(IClientRepositoryclientRepository,IOtherEntityRepositoryotherEntityRepository){_clientRepository=clientRepository;_otherEntityRepository=otherEntityRepository;// Register validations per action name here// vvvvv_validationsPerEndpoint=newDictionary<string,Func<AuthorizationFilterContext,Task<bool>>>(StringComparer.OrdinalIgnoreCase){{nameof(SomethingController.Post),ValidatePostAsync},// Register validations for other methods here...};}publicasyncTaskOnAuthorizationAsync(AuthorizationFilterContextcontext){varactionName=((ControllerActionDescriptor)context.ActionDescriptor).ActionName;try{varvalidation=_validationsPerEndpoint[actionName];varisValid=awaitvalidation(context);// ^^^^^^^^^^// Grab and run the validation for the called endpointif(!isValid){context.Result=newBadRequestResult();return;}}catch(Exception){// Log bad things here...context.Result=newBadRequestResult();}}privateasyncTask<bool>ValidatePostAsync(AuthorizationFilterContextcontext){varrequest=awaitGetRequestBodyAsync<AnyPostRequest>(context);// ^^^^^^^^^^^^^^^^^^^// Grab the request bodyif(request==null||request.ClientId==default){returnfalse;}varclient=await_clientRepository.GetByIdAsync(request.ClientId);// ^^^^^^// Check our client exists...if(client==null){returnfalse;}varotherEntity=await_otherEntityRepository.GetByIdAsync(request.OtherEntityId);if(otherEntity==null||otherEntity.ClientId!=client.Id)// ^^^^^^^^^^^// Check we're updating our own entity...{returnfalse;}// Doing something else here...returntrue;}// A helper method to grab the request body from the AuthorizationFilterContextprivatestaticasyncTask<T?>GetRequestBodyAsync<T>(AuthorizationFilterContextcontext){varrequest=context.HttpContext.Request;request.EnableBuffering();request.Body.Position=0;varbody=newStreamReader(request.Body);varrequestBodyJson=awaitbody.ReadToEndAsync();request.Body.Position=0;if(string.IsNullOrEmpty(requestBodyJson)){returndefault;}varsettings=newJsonSerializerSettings{NullValueHandling=NullValueHandling.Ignore};varrequestBody=JsonConvert.DeserializeObject<T>(requestBodyJson,settings);returnrequestBody;}}
On the OnAuthorizationAsync() method, this filter grabbed the validation method based on the called method name. And, inside the validation method, it checked that the request had a valid “clientId” and the referenced entity belonged to the same client. This is to prevent any client from updating somebody else’s entities.
Also, notice we needed to use the EnableBuffering() and reset the body’s position before and after reading the body from the AuthorizationFilterContext.
On the controller side, we registered the filter with an attribute like this,
usingMicrosoft.AspNetCore.Mvc;usingRecreatingFilterScenario.Filters;namespaceMyAuthorizationFilter.Controllers;[ApiController][Route("[controller]")][ServiceFilter(typeof(MyAuthorizationFilter))]// ^^^^^^^^^^^publicclassSomethingController:ControllerBase{[HttpPost]publicvoidPost(AnyPostRequestrequest){// Beep, beep, boop...// Doing something with request}// Other methods here...}
And, to make it work, we also need to register our filter in the dependencies container.
To test an ASP.NET async filter, create a new instance of the filter passing the needed dependencies as stubs. Then, when calling the OnAuthorizationAsync() method, create a AuthorizationFilterContext instance attaching the request body inside a DefaultHttpContext.
Like this,
usingMicrosoft.AspNetCore.Http;usingMicrosoft.AspNetCore.Mvc;usingMicrosoft.AspNetCore.Mvc.Controllers;usingMicrosoft.AspNetCore.Mvc.Filters;usingMicrosoft.AspNetCore.Routing;usingMoq;usingNewtonsoft.Json;usingRecreatingFilterScenario.Controllers;usingRecreatingFilterScenario.Filters;usingSystem.Text;namespaceMyWeirdFilterScenario.Tests;[TestClass]publicclassMyAuthorizationFilterTests{[TestMethod]publicasyncTaskOnAuthorizationAsync_OtherEntityWithoutTheSameClient_ReturnsBadRequest(){varsameClientId=1;varotherClientId=2;varotherEntityId=123456;varfakeClientRepository=newMock<IClientRepository>();fakeClientRepository.Setup(t=>t.GetByIdAsync(sameClientId)).ReturnsAsync(newClient(sameClientId));varfakeOtherEntityRepository=newMock<IOtherEntityRepository>();fakeOtherEntityRepository.Setup(t=>t.GetByIdAsync(otherEntityId)).ReturnsAsync(newOtherEntity(otherClientId));varfilter=newMyAuthorizationFilter(fakeClientRepository.Object,fakeOtherEntityRepository.Object);// ^^^^^^// Create an instance of our filter with two fake dependenciesvarrequest=newAnyPostRequest(sameClientId,otherEntityId);varcontext=BuildContext(request);// ^^^^^^^^^^^^// Create an AuthorizationFilterContextawaitfilter.OnAuthorizationAsync(context);Assert.IsNotNull(context.Result);Assert.AreEqual(typeof(BadRequestResult),context.Result.GetType());}privateAuthorizationFilterContextBuildContext(AnyPostRequest?request){varhttpContext=newDefaultHttpContext();varjson=JsonConvert.SerializeObject(request);varstream=newMemoryStream(Encoding.UTF8.GetBytes(json));httpContext.Request.Body=stream;httpContext.Request.ContentLength=stream.Length;httpContext.Request.ContentType="application/json";// ^^^^^^^^// Attach a JSON bodyvaractionDescriptor=newControllerActionDescriptor{ActionName=nameof(SomethingController.Post)// ^^^^^^^// Use the endpoint name};varactionContext=newActionContext(httpContext,newRouteData(),actionDescriptor);returnnewAuthorizationFilterContext(actionContext,newList<IFilterMetadata>());}}
Let’s unwrap it. First, we created an instance of MyAuthorizationFilter passing the dependencies as fakes using Moq. As stubs, to be precise.
To call the OnAuthorizationAsync() method, we needed to create an AuthorizationFilterContext. This context required an ActionContext. We used a Builder method, BuildContext(), to keep things clean.
Then, to create an ActionContext, we needed to attach the request body as JSON to a DefaultHttpContext and set the action descriptor with our method name. Since we didn’t read any route information, we passed a default RouteData instance.
Notice that we needed to use a MemoryStream to pass our request object as JSON and set the content length and type. Source.
With the BuildContext() method in place, we got the Arrange and Act parts of our sample test. The next step was to assert on the context result.
Voilà! That’s what I learned about unit testing ASP.NET authorization filters. Again, a Builder method helped to keep things simple and easier to reuse.
Want to write readable and maintainable unit tests in C#? Join my course Mastering C# Unit Testing with Real-world Examples on Udemy and learn unit testing best practices while refactoring real unit tests from my past projects. No more tests for a Calculator class.
This is a lesson I learned after trying to use a shared NuGet package in one of my client’s projects and getting an ArgumentNullException. I had no clue that I needed some configuration values in my appsettings.json file. This is what I learned.
Always check for missing configuration values inside constructors. In case they’re not set, throw a human-friendly exception message showing the name of the expected configuration value. For example: ‘Missing Section:Subsection:Value in config file’.
A missing configuration value
This is what happened. I needed to import a feature from a shared Nuget package. It had a method to register its dependencies. Something like services.AddFeature().
When calling an API endpoint that used that feature, I got an ArgumentNullException: “Value cannot be null. (Parameter ‘uriString’).” It seemed that I was missing a URI. But what URI?
Without any XML docstrings on the AddFeature() method, I had no other solution than to decompile that DLL. I found a service like this one,
publicclassSomeService:ISomeService{privatereadonlyUri_anyUri;publicSomeService(IOptions<AnyConfigOptions>options,OtherParamotherParam){_anyUri=newUri(options.Value.AnyConfigValue);// ^^^^^^^// System.ArgumentNullException: Value cannot be null. (Parameter 'uriString')}publicasyncTaskDoSomethingAsync(){// Beep, beep, boop...// Doing something here...}}
Then I realized that a validation inside the constructor with a human-friendly message would have saved me (and any other future developer using that NuGet package) some time. And it would have pointed me in the right direction. I mean having something like,
publicclassSomeService:ISomeService{privatereadonlyUri_anyUri;publicSomeService(IOptions<AnyConfigOptions>options,OtherParamotherParam){// vvvvvvvif(string.IsNullOrEmpty(options?.Value?.AnyConfigValue)){thrownewArgumentNullException("Missing 'AnyConfigOptions:AnyConfigValue' in config file.");// ^^^^^^^^// I think this would be a better message}_anyUri=newUri(options.Value.AnyConfigValue);}publicasyncTaskDoSomethingAsync(){// Beep, beep, boop...// Doing something here again...}}
Even better, what if the AddFeature() method had an overload that receives the expected configuration value? Something like AddFeature(AnyConfigOptions options). This way, the client of that package could decide the source of those options. Either read them from a configuration file or hardcode them.
The book “Growing Object-Oriented Software Guided by Tests” suggests having a StupidProgrammerMistakeException or a specific exception for this type of scenario: missing configuration values. This would be a good use case for that exception type.
Voilà! That’s what I learned today: always validate configuration values inside constructors and use explicit error messages when implementing the Options pattern. It reminded me of “The given key was not present in the dictionary” and other obscure error messages. Do you write friendly and clear error messages?