83 posts tagged with "programming"

Entity Framework Core has a few changes that impact unit testing, particularly with respect to EntityEntry.State management. My previous unit testing techniques also did not take into account the use of async methods. In this article I'll present a few techniques used in the context of a POC exploration of IdentityServer4. Although .NET Core 3 is now fully available, these examples are based on .NET Core 2.2.

Background​

IdentityServer4 has a ConfigurationDbContext that provides access for managing Client entities, along with an interface IConfigurationDbContext. While IdentityServer4's infrastructure handles all of the OAuth processing, CRUD operations for clients is left up to us. Therefore I created a ClientsController and a ClientRepository, and injected the interface into the repository.

In Making a Mockery of Extension Methods - way back in 2014 - I wrote about a technique for a code workaround that would facilitate replacing extension methods (global static methods) with mock objects for unit testing. Over the years I've used this technique a few times and found two major problems:

1. The technique of static delegate substitution is simply strange and requires too much thinking / analysis for good maintenance.
2. The unit tests are brittle, often failing on the first try due to multiple tests interacting with each other as they replace the static delegate.

Interestingly, I've found the second to be true with both XUnit and NUnit, even when supposedly running tests serially. This problem did not occur as frequently when I first started using the technique five years ago; I was using VS Tests or NUnit 2 back then, so perhaps the more recent brittleness is from the change in frameworks.

At last I grew tired of the technique and decided it would be better to simply replace it with something more familiar: an injectable class. Thus the recipe:

1. For a large set of extension methods over unmockable code - for example extension methods around database interaction - best to go ahead and create a thin adapter layer with an interface and constructor injection.
2. For a small static method over unmockable code, consider a small class with optional interface for either constructor or property injection.
3. If tempted to introduce a global static for any reason, consider instead using of these two techniques.

Working with a legacy codebase using NUnit and .NET Framework, I've found that there is a mix of NUnit assertions and assertions using the Should library. This library is rather old and, frankly, limited compared to Shouldly and FluentAssertions. These newer two frameworks are significantly more expressive, with APIs that cover myriad situations elegantly. Questions in front of me:

1. Are any of these libraries really worthwhile compared to simply using NUnit's built-in assertions - either traditional or Assert.That style?
2. If using any independent framework, which is the best choice for this code base?
3. If selecting Shouldly or FluentAssertions, ought we to upgrade the old asserts?

My conclusion: favor Shouldly. Upgrade old asserts opportunistically for consistency, but no need to go out of the way.

Problem​

I had just upgraded NuGet packages - a seemingly innocent thing to do. Everything compiles fine and I tried to run my ASP.NET WebAPI service. Testing in Postman works fine, but when I try to let the browser call an endpoint (any endpoint), I get a mysterious 500 server error with a rather unhelpful payload message of {"message":"An error has occurred."}. However, even with Chrome accessing the service, a breakpoint in the endpoint showed me that the code was executing fine. The problem is clearly occurring inside the ASP.NET engine when trying to send the response back to the browser.

The API for FlightNode is essentially structured along the lines of the onion architecture concept. Follow that link for a full description of the concept. Because my graphics toolkit is currently limited, my diagram for FlightNode has boxes instead of concentric onion-looking circles...

This release candidate nearly wraps up the user management and volunteer work tracking functionality. There are a small few "should have" features that will be added in a future release. So what's new?

The .NET projects for FlightNode were created in several different Git repositories, thus giving us several small, well-contained, and re-usable projects. These small projects would be installed into the Service project as NuGet packages, which also makes for a faster compile in each discrete solution:

1. FlightNode.Common
2. FlightNode.DataCollection
3. FlightNode.Identity

But… this has approach has caused problems.

The first beta release of FlightNode is now alive and in the hands of testers. So what's been delivered?

Wow, you'd think nothing had been happening for the past two months. But that's not the case at all. There are now 6 different GitHub repositories (perhaps a few too many). November and December were heads-down coding months. But now the product is almost ready for an MVP launch... and that has me thinking about error handling. Specifically, logging.

Originally I decided to look into NLog for .NET logging, a product I've never used before. I have experience with the Enterprise Library logging block and with Log4Net, and find them both to be useful but not as... pleasant... as I would like. They don't have the interface I would prefer. But they work. It turns out NLog has basically the same interface, and the same tedious configuration.

In order to run FlightNode locally:

1. Retrieve all Repositories​

Make local copies of all the repositories mentioned in the Architecture page. Be sure to configure an upstream remote and follow the workflow described in Git Tutorials, Workflow, and GUI.

2. Start the Identity API​

Open the FlightNode.Identity solution in Visual Studio 2015. Open the Package Manager Console (menu: Tools > NuGet Package Manager > Package Manager Console).