Skip to main content

31 posts tagged with "testing"

View All Tags

Best Practices in TDD and OOD

· One min read

Spurred on by the goal of giving a brown bag tech talk on the subjects of test-driven development and SOLID object oriented design principles, I've finally collected all of the "wisdom" I've learned over the years into one place: Best Practices in Test-Driven, Object Oriented, Green- and Brownfield Development. I plan to keep this as a living document, adding or modifying as I continue to deepen my knowledge through feedback, study, and further experiments.

Unit Testing with Entity Framework Core and Async

· 5 min read

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.

Refactor Away from Global Static

· 5 min read

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.

Comparing Assertion Libraries for .NET Framework

· 7 min read

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.

Upgrading safnet-directory, Part 2: Unit Tests

· 6 min read

Continuing from Upgrading safnet-directory, part 1, it is time to improve the solution's unit testing. At the outset, the controllers cannot be unit tested effectively due to their direct dependence on Entity Framework and ASP.NET Identity Framework classes. With application of an in-memory database, they could be integration tested, but not unit tested as I understand and apply the term.

API Calls from Postman Work, But Not From the Browsers

· 2 min read

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.

Refactoring Legacy Web Forms for Test Automation

· One min read

The Challenge:

Given you understand the value of test automation. Given you are handed a legacy application to maintain and enhance. Given the application is in ASP.Net Web Forms. When you try to add tests. Then you find that test-driven development is literally impossible.

Here's one solution, in long slide-style presentation:

Unit Test Isolation for Legacy .Net Code

· 3 min read

Isolating code from dependencies is crucial for developing small, well-defined, easy-to-understand tests. And it is an absolute must when those dependencies call external resources, such as a database, filesystem, or heavy-duty component (e.g. for interacting with office docs). But how do you introduce isolation in new unit tests for legacy .Net code? Well, that depends... and I have a flow chart and brief notes to help you figure it out.

Test toolkit flow chart

safnet logo