DEV Community: Jon Dodd

AI in Software Development: A Mirror, Not a Magic Wand

Jon Dodd — Fri, 13 Mar 2026 08:00:00 +0000

Introduction

“AI’s inflection point has arrived.” This statement reflects how deeply artificial intelligence is embedding itself into our daily lives. For software developers, that reality is unavoidable. Whether you’re using GitHub Copilot for small productivity gains or experimenting with more advanced agentic workflows, AI-assisted development is here to stay — and learning to use it well is quickly becoming essential.

"AI’s inflection point has arrived." — Jensen Huang, NVIDIA CEO

Yet scratch beneath the surface and you’ll find sharply mixed opinions. Some developers praise AI for dramatic productivity gains. Others argue it introduces subtle bugs, encourages shallow understanding, and accelerates the creation of tomorrow’s legacy code.

I believe both sides are right.

Two Core Premises to Keep in Mind

How can two seemingly contradictory viewpoints both be true? The answer lies in two simple premises.

1. AI does not change the need for good engineering discipline

AI can assist you, but it does not replace understanding. If you already follow best practices and think carefully about design, correctness, and performance, AI will help you move faster. If you don’t, it will happily help you make things worse — just more quickly.

AI shortens feedback loops. Hours of work can now become minutes. That speed is powerful, but it is neutral. Whether it improves or degrades a codebase depends entirely on the developer using it.

Which leads directly to the second premise.

2. AI amplifies whatever habits you already have

Careful developers → faster, still careful
Sloppy developers → faster, more sloppy

If you stop thinking of AI as a replacement for developers and instead see it as an amplifier of existing workflows, the current state of AI-assisted development starts to make much more sense.

The Multiplier Effect in Practice

To see how this plays out, let’s look at what happens when AI meets different development styles.

The “Sloppy Dev” Scenario
What does “faster, more sloppy” look like in practice?

Imagine a rushed or inexperienced developer who blindly accepts a large block of AI-generated code without fully understanding it — ignoring algorithmic complexity, edge cases, or even hallucinated dependencies. AI allows them to generate technical debt at 10× speed.

For example, a developer needs to process a list of users and find duplicates based on email address. They prompt an AI assistant and immediately accept the following C# code:

The code “works” locally with ten test users. The developer merges it and moves on.

In production, with 100,000 users, this nested loop (O(n²)) combined with repeated .Contains() calls severely degrades performance. The problem wasn’t AI — it was the lack of review and understanding. AI simply accelerated the damage.

The “Careful Dev” Scenario

Now contrast that with a disciplined developer.

A senior engineer might use AI to scaffold a REST API, generate boilerplate, or sketch an initial solution. But they treat the AI like a junior pair programmer — not an authority. They review the output, question it, and improve it before shipping.

Using the same duplicate-finding problem, the careful developer immediately spots the performance issue and re-prompts the AI.

The AI enthusiastically apologizes and offers this "optimized" solution:

The sloppy developer would have merged this, thrilled that it runs faster. But the careful developer goes a step further: they actually read the code to ensure logical soundness. In doing so, they spot a subtle, dangerous flaw.

This code misses the first record. HashSet.Add returns true for the first instance of an email, so it bypasses the if block. If there are two users with the same email, this function only returns the second one. The AI generated code that looks confidently correct but contains a subtle logical flaw caused by an implicit assumption.

Because the careful developer understands their tools, they discard the AI's flawed logic and write a definitive, bug-free, and idiomatic C# LINQ query instead:

The careful developer used AI to get the initial momentum, but they applied their own engineering rigor to ensure the solution was performant, clean, and logically perfect.

The important point isn’t that the AI made a mistake — it’s that only a disciplined developer noticed.

The Engineering Discipline Checklist

To consistently benefit from AI rather than fight it, a few foundational habits matter more than ever.

Design incrementally
AI struggles with whole systems but excels at focused tasks. Architect the system yourself, then ask AI to help with specific components — a repository, a mapping function, a DI configuration. Smaller prompts produce cleaner results.
Test as you go
When code is generated at high speed, guardrails are essential. AI can produce logic that compiles perfectly but fails subtly. Strong unit tests (xUnit, NUnit, etc.) catch these issues early and cheaply.
Review what you merge
Code review is now critical, even for solo developers. You may not have written every line, but you still own every line you commit. Treat AI-generated code exactly like code from a human teammate.
Stop when the problem is solved
AI will happily keep elaborating long after a solution is good enough. Knowing when to stop refining is a human skill — and an underrated one.

Conclusion

If you take nothing else away, remember these two points:

AI does not remove the need for good engineering discipline
AI amplifies whatever habits you already have
Software development is evolving rapidly, but responsibility hasn’t moved. The tools are getting smarter — but they still reflect the discipline, or lack of it, of the developer holding the keyboard.

If you’re interested in how these ideas translate into real projects, I’ve written more about how we approach maintainable .NET application development — focusing on clean code, sensible design, and long-term maintainability rather than chasing hype.

Inherited a .NET Nightmare? 5 Strategies to Tame Legacy Code

Jon Dodd — Thu, 05 Mar 2026 07:00:00 +0000

Introduction

As a developer, it is almost inevitable that you’ll eventually work on maintaining or modernising an existing codebase. Rarely is this straightforward; the challenge can feel overwhelming, especially if the core logic is a tangled mess and a classic ‘big ball of mud’. This lack of clarity decreases your confidence and increases the risk of the system breaking in unexpected places whenever you make changes.

What is legacy .NET code?

A common misconception is that legacy code must be old code. While age can be a factor, a system might use modern frameworks but still be poorly organised and patched together to meet a deadline. While many factors define legacy code, we’ll focus on two of the biggest ones today.

First, if the code has no tests, it is legacy. Michael Feathers^1^ famously defined legacy code as “code without tests” because the absence of a safety net makes changing the system risky and expensive.

Second, if the code and infrastructure have no automated deployments, it is legacy. Modern software hosted on cloud infrastructure should be readily deployable via automation. If a release requires intricate manual interventions from a developer's workstation, the risk of redeploying the app is simply too high.

Should I rebuild my .NET application?

When inheriting a large .NET monolith, scrapping it and starting from a clean slate seems incredibly appealing. It’s a tempting thought, but the "Big Bang" rewrite is almost always a trap.

These massive rewrites consistently take longer than estimated because developers often base their timelines on a superficial analysis of the screens or APIs. This approach frequently misses undocumented business rules buried deep in the codebase, which sometimes aren't discovered until bugs are raised in production. Furthermore, new development grinds to a halt until the rewrite is complete; spending two years adopting new tech without innovating can cause a business to lose out financially and competitively.

What can I do to modernise my .NET legacy application?

If we rule out the big rewrite, how do we move forward? First, you need to adopt a specific mindset: Adopt a cautious, deliberate approach.

With large, tangled codebases, rushing in can introduce unknown bugs to other parts of the system. You must tread cautiously. For instance, you might spot a guard clause at the beginning of a method that seems to serve no purpose and delete it, only for issues to emerge in the next release. This perfectly illustrates Chesterton’s fence ↗: just because a piece of legacy code shows no obvious purpose to you, it doesn’t mean it isn’t important.

What strategies can I use to modernise my .NET codebase?

Once you have the right mindset, you can start applying tactical solutions. Here are five proven strategies to regain control of your .NET application.

1. Characterisation Testing: Build Your Safety Net

One of Michael Feathers’ most critical strategies is locking-in the system's existing behaviour, even if it is buggy. Characterisation tests assert what the system actually does right now, not what it should do. The goal isn't to fix the logic immediately, but to create a testable benchmark. Once you have this safety net proving how the system behaves, you can refactor the messy code with confidence that you haven't lost an undocumented business rule.

2. Sprout and Wrap

When strict time constraints prevent you from refactoring the surrounding mess, Feathers suggests two techniques to safely add functionality. The Sprout technique involves writing your new feature as a completely new, fully tested method or class, and then simply inserting a call to it from within the legacy code. Alternatively, the Wrap technique has you rename the old method, create a new method with the original name, and have that new method execute both the old logic and your new additions.

3. The Boy Scout Rule

Popularised by Robert C. Martin (“Uncle Bob”), the Boy Scout rule ↗ is simple: “Always leave the code cleaner than you found it”. If you are updating a method, take a moment to rename vague variables to provide clear meaning, or remove unused parameters. These small improvements compound over time, leading to vastly better maintainability. Equally important is applying this rule to your test suite; cleaning up your tests increases your confidence in the whole system.

4. The Strangler Fig Pattern

If your goal is to modernise a monolith into a modular architecture, the safest route is the Strangler Fig Pattern (a concept championed by Martin Fowler ↗). Imagine you have a massive, ten-year-old ASP.NET Web Forms app, and your operations team desperately needs a new mobile-friendly "Driver Dispatch" module.

Instead of rewriting the whole logistics system, you place a routing proxy (a "Traffic Cop") in front of the legacy app, initially routing 100% of traffic to the old system. Next, you build the new "Driver Dispatch" feature inside a cleanly architected and testable .NET application. If your internal team is bogged down maintaining the old monolith, this is often a great time to leverage expert .NET application development services to ensure the new architecture is built right from day one. Finally, you update the proxy rules so that billing clicks go to the old system, but dispatch clicks route seamlessly to the new app. Users utilise both systems simultaneously without noticing, allowing you to slowly extract modules over time.

5. Automate the "Magic" Deployments

If your system requires a developer to manually execute SQL scripts, copy .dll files, or right-click "Publish" in Visual Studio, you cannot safely modernise it. Refactoring demands frequent, low-risk deployments, whereas manual deployments are infrequent and high-risk. Before touching the core architecture, codify those "magic" steps into a CI/CD pipeline using tools like GitHub Actions or Azure DevOps. Knowing you can reliably compile, test, and deploy at the push of a button removes a massive amount of stress from your rescue mission.

Conclusion

Rescuing legacy software isn't about writing the cleverest C#; it’s about managing risk. These five strategies are just the beginning of making controlled, incremental changes to maintain or modernise a legacy .NET system.

Don’t be put off if you inherit a complex legacy application. By building a test safety net, making small controlled changes, ensuring code is testable, and automating your deployments, you can transform a terrifying legacy system into a manageable one. With patience, care, and the right workflow, any codebase can be brought under control to meet your business needs.

1: Feathers, Michael C. (2005). Working Effectively with Legacy Code

In Memory Automated UI Testing ASP.NET Core

Jon Dodd — Fri, 05 Nov 2021 15:53:04 +0000

Introduction

In this article we look at how to run in-memory automated UI tests for an ASP.NET Core web app using Playwright and NUnit.

The article provides demo code and solutions to issues found along the way.

Automated UI Testing

Automated testing of any web application is essential to ensure it functions correctly. On the top of the “testing pyramid” proudly sits UI testing or end-to-end testing, above integration and unit testing. Automated UI testing involves launching and controlling a browser to drive through a set of interactions that a user would perform. Assertions are made to see if the web app and browser behave as expected. Browsers are controlled by testing tools such as Selenium, Puppeteer or the new kid on the block, Playwright.

Normally, tests are run against a web application deployed to a test environment which has been configured with the same infrastructure as the production environment. However, in this post we will be looking at running our UI tests against an in-memory instance of a web application. By running the test in this way, we can:

Develop tests faster.
Reconfigure the app with test configuration.
Catch some errors earlier in the dev/test process.
Still run the tests against a deployed environment later.

Before we get started, we need to take a small step back.

Integration testing with WebApplicationFactory

Microsoft provide a neat way to run integration tests using an in-memory web server called TestServer.

Using the WebApplicationFactory class will provide you with a running TestServer. It requires a type in the entry point assembly of the application. Typically the Startup or Program classes can be used. The WebApplicationFactory class also provides a virtual ConfigureWebHost() method, which allows for the web host to be manipulated. This is powerful and means services can be removed, added, or swapped. For example, a SQL Server database can be removed and replaced with an in-memory database.

A unit test framework such as xUnit or NUnit can be used to write and run the tests targeting the app hosted in the in-memory TestServer. When tests run they use an HttpClient connection given by the TestServer. The HttpClient is a C# class and is not a browser, which means its a bit limited and inconvenient to use.

Using the TestServer approach, we have an in-memory web server at our disposal. Not only that, it provides a way to override the way the webhost is built so that we can customise our application for our testing needs. That sounds great! Unfortunately, when using a browser automation tool, such as Selenium or Playwright, the TestServer approach does not quite work.

Modifying Test Server to Work with Selenium and Playwright

After reading some really useful articles by Ben Day, Bertrand Thomas and an oldie from Scott Hanselman (thanks guys!), I’ve derived a class from WebApplicationFactory which works with browser testing tools including Selenium and Playwright. In the demo project, this is the AutomatedTestServerFactory class.

One of the main issues when using a TestServer with a browser testing tool is that ConfigureWebHost() is not called. This means the app cannot be changed at start up to use a test configuration. In the “traditional” way of using TestServer, we are given an HttpClient instance for our request/response interaction with the server. The HttpClient instance is created using the CreateClient() method in WebApplicationFactory, which in turn runs the ConfigureWebHost() method. So, the really useful re-configuration we need is only done when an HttpClient is created! Browser testing tools effectively replace the client and are controlled independently of the TestServer.

To get round this issue, AutomatedTestServerFactory sets the configuration when the webhost is built. The work is mainly done in two methods CreateServer() and CreateWebHostBuilder(), which are called by the constructor.

CreateWebHostBuilder() is called first and sets the web host configuration, which is passed through as a constructor parameter. Also optionally set is the environment, otherwise the default environment is Production, which may not be ideal.

CreateServer() builds and starts the web application and begins listening for requests. This method returns a null TestServer. I didn’t see any impact of this and it avoids a new and different instance of the web app from being created.

With these changes in place, we have a WebApplicationFactory that creates an in-memory TestServer hosting our re-configured web application and is suitable for use with Selenium or Playwright. Super!

Using Selenium or Playwright

When developing this project, I started using Selenium as the browser testing tool, however I noticed in October 2021, that Microsoft updated the integration test article (see above) to recommend Playwright instead of Selenium. So I took a look, I liked it, and I have used Playwright for the remainder of the project. Playwright is a relatively new end-to-end testing tool developed and maintained by Microsoft.

The reasons I liked Playwright include its simplification of browser driver management, that it works with Chromium, Firefox and Webkit browsers and the ease of use of the API compared to Selenium’s. Out of interest, I found migrating tests from Selenium to Playwright to be straightforward too!

The decision to use Playwright also led to selecting NUnit as the test runner. Typically, I use xUnit for testing, but it doesn't support running Playwright tests in parallel.

Configuring Playwright on local PC

To get Playwright to work, there are two steps required using Package Manager Console:

Install Playwright CLI as a global tool.
- Run the command: install -g Microsoft.Playwright.CLI
Install browsers.
- Navigate to the path of the test project and run the command: playwright install

Code Time!

In order to demonstrate this working, I’ve created a demo application available on GitHub. The codebase has three parts as described below.

Employee System

This app is a very simple ASP.NET Core MVC application using EntityFrameworkCore with SqlClient. The only functionality is a homepage and a page returning a list of employees. This is enough for our purposes though! It has a migration script, so remember to run update-database before launching it.

This is what the Employee List page looks like:

Test code

The test code is comprised of two libraries, AutomatedTesting and Employees.UITests. The AutomatedTesting library contains the custom AutomatedTestServerFactory class to enable in-memory testing with Selenium or Playwright.

Employees.UITests is an NUnit test library. It contains a base class, BaseTestClass, which is responsible for creating the web server and passing in the required configuration, in this case changing the database to in-memory and adding test data. The base class is decorated with the attribute [Parallelizable(ParallelScope.Children)] to allow child tests to run in parallel.

The EmployeeListTests class inherits from BaseTestClass and focusses on the tests, so the code is quite clean. There are three tests, each one is the same, but using different browsers. Running the test project will cause all three tests to run in parallel. Finally, I’ve used FluentAssertions (as I like it!) for evaluating the outcomes of tests.

In the excerpt below, the Employee menu option is clicked and assertions are made on the output.

I have started to pull out some common tasks in TestHelper, such as taking a screenshot and attaching it to the test report.

After running the tests, you can see the results in the test log by right-clicking on a test and opening the log.

In Visual Studio 2019, the results include both the log messages and the screenshots.

Devops

I have included a yaml build pipeline for Azure DevOps. This configuration deals with the Playwright requirements, builds the code and executes the tests in a cloud-hosted Windows server. It can target a self-hosted Windows target too.

Resolved Issues

Developing this project was not without its issues. Apart from getting the AutomatedTestServerFactory to work, here are the issues I found and overcame.

Issues found on Developer PC

Issue 1:

The web application launches, but is missing styling, JavaScript and images. This was because the test server would launch in the bin directory of the test project and not have a reference to the wwwroot folder.

Solution: This was resolved by adding a post-build target to the Employees.UITests project file. The target copies the wwwroot folder recursively from the Employees.UI project to the Employees.UITests\bin folder.

Microsoft have an example of how to copy files recursively during after build.

Issue 2:

Microsoft.Playwright.PlaywrightException : Executable doesn't exist

Solution: One or more of the browsers is missing. Run playwright install command in the Package Manager Console, but significantly make sure this is done in the directory of the test project.

Issues found in Azure Devops

Issue 3:

Install step of Playwright Tool causes error when re-run. The following two lines in the log file indicate the issue.

Tool 'microsoft.playwright.cli' is already installed.
Error: The process 'C:\Program Files\dotnet\dotnet.exe' failed with exit code 1

Solution: Instead of calling dotnet install, run the dotnet update command as this removes and clean installs the tool.

Issue 4:

Error: Cannot find a tool in the manifest file that has a command named 'playwright'.

Solution: Make sure the playwright install command runs in the directory of the test project.

Issue 5:

Cloud-hosted Chrome fails with exception: Microsoft.Playwright.PlaywrightException : net::ERR_CERT_AUTHORITY_INVALID at https://localhost:5001/

Solution: Get a new browser instance to get round this issue using the code below. This effectively runs the tests in incognito mode.

await browser.NewContextAsync(new BrowserNewContextOptions { IgnoreHTTPSErrors = true });

Issue 6:

Firefox does not navigate to test site. Instead a warning is displayed in the browser

“Warning: Potential Security Risk Ahead”.

Solution: Firefox prevents navigation to another port on localhost. The warning requires manual intervention, but the settings can be overridden so that the automated test can run. To do so, set the following capabilities (these settings are briefly covered here):

caps.Add("security.insecure_field_warning.contextual.enabled", false);

caps.Add("security.certerrors.permanentOverride", false);

caps.Add("network.stricttransportsecurity.preloadlist", false);

caps.Add("security.enterprise_roots.enabled", true);

Other points:

Firefox not waiting for AJAX request to complete.

When waiting for a page to load that fires off an AJAX request, for example fetching data on page load, Firefox does not seem wait. To resolve add await WaitForLoadStateAsync() after the command to load the page.

Azure DevOps only includes NUnit log on test failure.

NUnit provides the convenient TestContext.Out to log messages during testing. These will always appear using the test runner in Visual Studio 2019, but these messages are only present in Azure Devops when a test fails.

Conclusion

In this article we have explored through the code, configuration and gotchas of running automated UI tests of an ASP.NET Core web app using Microsoft’s TestServer. We have been able to perform UI testing using Playwright with multiple browsers running in parallel using NUnit.

We have seen a number of issues, mainly arising in Azure DevOps, and how to overcome them.

In-memory automated UI testing could be great for smaller systems and to help develop test code. It's not an approach for all cases, but certainly has its merits.

Finally, if you’ve not used Playwright for automated testing, perhaps it is a good opportunity to try it out!

Practical complex data for unit testing

Jon Dodd — Thu, 09 Sep 2021 12:44:28 +0000

Unit testing is a long-established and essential part of the software development process particularly when using .NET. The basic premise, if you are not aware, is to test the public methods of classes so that they work as expected.

Unit tests follow the 3As: Arrange, Act and Assert. In other words, set up the conditions for the test, run the code and finally, check that it worked as expected. If it did, great the test passed! If not, then there’s some work to do.

This article takes a look at the first step, arranging the test. Although there are a few things to do during this stage, right now we are only concerned with creating the data required to run the test.

Later, we are going to look at how to create complex test data that can be easily understood by using the Builder pattern.

Why is it important how test data is created?

Well, the test data can be confusing to look at and to understand. It becomes time-consuming to follow and to update. This is especially the case where the test data has relationships to be maintained.

If the test data is not clear it is easy to make a mistake and introduce bugs into test code.

Test data which was written a long time ago becomes hard to recall. As with everything it is fresh in the mind when it is written, but three or six months later, it becomes difficult to recall the intent of the data.

It is easy and very tempting at times to break the DRY (Don't Repeat Yourself) principle and just repeat test data. As new tests are set up, test data that is not well understood is typically copied and tweaked to suit the purpose. This just increases the technical debt within the test data making the whole project harder to maintain.

Arranging test data

Most, if not all code depends on parameters or data to run. So when it comes to unit testing and asserting that the code works some amount of data is usually required to run the test. This can range from a simple value-type parameter to a complex object model, or even a larger set of related data.

There are different ways of creating unit test data and we’ll take a look at some of them briefly.

Test data can be created in a unit test directly, passed into a test in line, loaded from files, or created for use in an in-memory database. I consider in-memory database fine for unit testing. A separate database hosted outside the test execution process would be considered integration testing.

Adding test data with xUnit Unit Test Framework

To manage and run my unit tests I use xUnit. It is a popular, free, open source and community-focused unit testing framework. xUnit provides a few useful ways to manage our test data.

Theory Unit Test

Theory unit tests allow a single test to act on sets of parameterised data . Data is passed using the InlineData data attribute for as many different cases as needed. This keeps the test code DRY and removes the need to repeat the test logic for different data values.

In cases where test data is complex, xUnit also supports ClassData and MemberData data attribute for loading test data in from a method or from another class. xUnit is extensible and custom data attributes can be written, for example, to load test data from files or from a database.

Fixtures

The final xUnit feature to look at is the Fixture class. Fixtures allow for sharing setup and clean up code for all tests in a class or even in multiple test classes. This is a great place to create complex test data and the perfect place for creating an in-memory database for the tests that require one.

For our development we often use SQL Server accessed via Entity Framework and to test we use SQLite in-memory database to simulate the database layer. We use this approach to initialise an in-memory database with the data we need which provides the context for a series of tests logically grouped in a class.

AutoFixture

One neat library for creating and generating test data is AutoFixture. The creators describe it as follows:

AutoFixture is an open source library for .NET designed to minimize the 'Arrange' phase of your unit tests in order to maximize maintainability. Its primary goal is to allow developers to focus on what is being tested rather than how to setup the test scenario, by making it easier to create object graphs containing test data.

We don’t use AutoFixture for our test data creation in this example, but it is worth mentioning as it can speed up the process of writing tests.

How the Builder Pattern can help create complex data

As touched upon before, there are issues that emerge when test data gets complex. Thankfully there is an approach which we can use to help us and has been around for a long time.

The builder pattern is a well-understood design pattern in software development. It allows the construction of complex objects step by step and can be used to create different representations of complex data.

This is great for our needs as we can use this approach to create our test data. The builder pattern enables us to create our test data with the intent clear. It does mean creating a concrete implementation of the pattern using knowledge of the domain.

However, I think this approach can be worthwhile as it gives us the following benefits:

Single place to instantiate objects
It leads to preventing the repetition of data
Provides a way of controlling each step of the construction process. This leads to the code providing a clear intent of the data.
The concrete implementation can be developed using domain-specific language. This also makes the intent of the data clearer. Name the builder methods as you wish to provide the most information to the developer/tester.
As the construction of the object is encapsulated in code, it can be designed so that foreign keys are handled in code which reduces complexity.
Also, it means collections are created when required. Collections can be navigated by accessing the last item by convention.

Builder Pattern In Action

For this project I used .NET Core 5.0, EFCore and SQLite. Also included is xUnit for unit testing, AgileMapper for mapping and Fluent Assertions for the assertions.

Our demo project is a nascent itinerary planner and is available on GitHub. It has a model based around tourists who have excursions containing visits to places (e.g. Paris) and visits to points of interests (e.g. Eiffel Tower).

The only bit of business logic is to swap the order of places to visit in an excursion. This logic is the code under test, has a dependency on a database and is encapsulated in a TouristService.

So now for the data. As mentioned before, we will simulate a database using an in-memory SQLite database as this will work nicely with our service under test. This will be added using an xUnit fixture class so that all tests in the class can share the same data. Finally, we have our custom implementation of the builder pattern used to create the test data.

What does the test builder look like?

The ITourist interface contains methods to create our Tourist. You can see that the builder enables the complex object model to be built step by step using method names that have domain relevance. Finally the BuildTourist method will return our object.

Now for a sample of the implementation.

Initially, we create our top-level object, a Tourist which is kept in a private field.

Next, we add an Excursion to our tourist.

All of the other steps are similar to the above to build up the object.

Finally, the BuildTourist method is implemented which returns our Tourist.

The test project includes an example of loading the data using the Builder pattern. The order and indentation of items is important for readability, but not essential.

For contrast, it also includes an example of loading the same test data by direct object creation.

Comparing these two different implementations it is easy to see that using a Builder, the test data is more readable and easier to maintain.

Now on to the unit tests. The TestsWithFixtureAndBuilder class uses the Fixture where our test data is created. The test class contains a single test to check that the SwapPlaceVisits method works as expected.

Remember to check out the entire code example in GitHub.

Further ideas for the Test Data Builder

As this is custom code, there is a huge amount of flexibility available and you can enhance the basic test data builder to:

Include validation rules. This can be useful for ensuring the business logic constraints are correct before running a test and ensuring your test data is correctly formed.
Set the primary keys automatically. Depending on how the tests are set up in your specific case, there could be the chance to set the primary keys in the builder.
Create model with default values and update specific values only. This can be done using lambda functions.
Add plain English descriptions to the builder and override the ToString() method. Textual information can be added inline. This could also be outputted during unit test execution to help debug problematic tests.
Add factory methods to generate common test data.

Conclusion

As we’ve seen, there are many ways of creating test data. However, when the data starts to become complex it can become difficult to understand and maintain and lead to complications with our unit tests. The builder pattern has been around for a long time and it has proven to be useful when creating test data to give context and make the test data easy to understand and maintain.

Hopefully this article and code example will provide some useful pointers to building your test data. Beyond this specific code example, the take home points are to find the approach which works best for you and the rest of your development and testing team. So when creating test data, aim for the following:

The test data is easy to understand.
The relationship of the data is easy to understand.
The data is easy to change or add.
The approach ensures developers stick to the DRY principle.

Fluent Assertions 10 Top Tips

Jon Dodd — Tue, 22 Jun 2021 11:29:09 +0000

Introduction

The value of writing unit tests is well understood these days and there are some really useful frameworks and tools which developers depend upon.

One such library is Fluent Assertions. It is an open source library that integrates with several Microsoft platforms such as .NET or .NET Core, and supports several testing frameworks including MS Test, NUnit and XUnit. The main motivation for its development is to show clear error messages returned by failed tests. Fluent Assertions has many extension methods which can improve the efficiency and readability of unit test code. The project allows for descriptive outcomes which suits TDD and BDD testing methodologies, but it is useful even if unit tests are written after the main code!

For our backend development, we code mostly in C# and use XUnit as our testing framework. We introduced Fluent Assertions on a project a couple of years ago to help make our assertions cleaner as we particularly liked the concept of Assertion Scopes (more on that later). Since then, we’ve continued to use Fluent Assertions, but we have used it in a limited way using the same set of features.

However, recently I felt it was time for a knowledge refresh of Fluent Assertions and it has revealed plenty of opportunities for us to improve our unit test code.

This article covers my ten top tips for using Fluent Assertions from this recap. If you are using this library in your tests, then hopefully there’s a tip or two that helps you out. This article covers the features that have jumped out at me, but there are many more useful features in the library.

It is assumed that you have a basic knowledge of Fluent Assertions or are actively using it. If you don’t, fear not, you can always skim through the docs later!

10 Top Fluent Assertion Tips

So, here are my ten top tips that I will keep in mind from now on when writing unit tests.

At the time of writing Fluent Assertion v5.10.3 was used.

1. Use object graph comparison

Some of the early test code we wrote was comparing object graphs and we were writing out property to property comparisons. As you can imagine, this was quite tedious!

Fluent Assertions has a really useful extension method BeEquivalentTo(). This allows object graph comparison and therefore removes the need to list all properties for comparison. This reduces the time required to write the test code and there is less of it to read and maintain.

BeEquivalentTo() is very powerful and has plenty of options. Among its features, you can select properties and/or fields to include or exclude, specify collection order, and it has a diagnostics mode to help debug deep into object graphs.

2. Use Date formatting extension methods

There are a set of date formatting extension methods which allow for dates and times to be written more expressively. This approach provides clarity which is useful for non-developers to understand the test code.

3. Use DateTime and TimeSpan assertions

There are lots of useful assertions for dates and times and using them helps to make the code more readable. Use these extensions to replace the traditional code comparison operators.

One other point to mention, a date can be checked that it falls within a certain timeframe.

4. Use Collection extension methods

Beyond the typical collection assertion methods you would expect to find, such as checking the count, there are some powerful methods to perform assertions on collections and the items they contain. These include asserting the order of the items, checking for uniqueness and whether a collection is a subset of another collection.

Other powerful methods include Contain and ContainSingle, these help validate that at least one or exactly one item in the collection meets a criteria.

Finally, SatisfyRespectively is a method which allows you to perform complex assertions on each item in a collection.

5. Use Which

The Which extension allows for another assertion to be chained onto a previous assertion that identifies a single item in a collection.

6. Use Exception Assertions

In our code we are using the exception assertions for top-level exception type checking. However, there is more that can be done! Using WithMessage allows us to check the message content is as expected. Also, it is possible to check the inner exception and the individual properties of the exception.

7. Use Perform Assembly Assertions

In many of the systems we develop we use a layered architecture, specifically the Onion Architecture. This architecture states that code can only reference immediate inner layers. Fluent Assertions provides a pair of useful assertions to check that this rule is enforced at the assembly level.

8. Improve Should().BeTrue() code

Ok, so this is actually a tip from the Fluent Assertions documentation itself! If the code is not evaluating a Boolean directly, then it is likely that Should().BeTrue() assertions can be written using a more expressive assertion syntax. This will improve readability and the error message displayed. There are myriad examples in the documentation to check out.

9. Use AssertionScope

This is something that we already use and it is quite a fundamental feature, but it is worthwhile mentioning. By using the using (new AssertionScope()) { } code block, all assertions are evaluated and if the test fails, the error will include all messages from multiple failed assertions.

10. Other points

Finally, a couple of other things were noticed when reading through the docs. Neither of these features we currently need to use, but they are now kept in mind:

Can perform execution time assertions to check code performance.
Can perform XML assertions on LINQ-to-XML classes.

Conclusion

We like Fluent Assertions for the benefits of clear error messages, more readable test code and that fewer lines of code are needed for our tests. We are pleased to have refreshed our knowledge in this area and we can improve our future tests as well as refactor older ones.

This exercise taught us an important lesson in general. The world of software development is ever-changing and it pays dividends to keep up to date with existing tools.

Refreshing your knowledge of the libraries, tools and frameworks you use will provide valuable benefits to you, your code and those you work for.

Our top tech news & programming sites

Jon Dodd — Fri, 11 Jun 2021 10:59:33 +0000

Did you know that there are just sixty years between the very first flight and the presence of the first man on the moon? That’s an incredible rate of technical innovation.

Today, it seems that technology advances at an ever-increasing pace. As businesses and individuals have become more digitally dependent, investment has flowed in to the tech sector and innovation has flourished creating a rich diversity of devices, platforms, development languages.

To see how quickly things change you just need to cast your mind back to the year 2000. This was a time before today’s age of cloud computing, smartphones, internet of things (IoT) and big data. Wow, so much has changed!

However, for all the success stories, there are failures and certain advances which have not caught on. Also, even over a relatively short period of time the latest and greatest concept can be quickly forgotten with something new and improved.

Part of the role at a software development company is to keep abreast of these technology changes. It is a continuous exercise to decide on which technology is here for the long-term, when to be ready to shift when something is rapidly losing its place, and to avoid the also-rans. There are a few ways this is done, but one of them is as simple as reading and keeping well informed.

Fortunately the internet contains a huge resource of written content, and technologists and experts are generally happy to share their knowledge.

This article covers some of our favourite places we often visit to remain au fait with the technology trends which are most relevant to software development.

The Register

The Register is a popular technology news site in the UK and covers all major stories that we need to know about. It has a humorous edge to its content which makes it a pleasure to read even about quite dry topics.

https://www.theregister.com/

Slashdot

Slashdot is a social news site which covers technology, science and politics. It has been running since 1997. Submissions come from various sources so it is an effective way to get an aggregated news feed of sorts. Despite its U.S leaning, it is possible to pick up essential technology news.

https://slashdot.org/

Medium

Medium is a popular blogging site for a range of topics and has been active since 2012. It aims to publish high quality well-written articles and its content can be monetized. It is another great resource for technical and programming content and tags can be used to filter content.

Over the years, we have read many specialised articles to improve our knowledge. We also find many of the articles are opinionated which provides a good basis for discussion. Reading the comments of these articles often provides a good insight on what a larger group of people think about a specific technology, tool or framework. At times this informs our decision making.

https://medium.com/tag/programming

Dev

Dev is a developer community site where developers can contribute articles, be part of discussions and find out about products and services. The site’s purpose is for collaboration and networked learning for developers. Currently it boasts over 400,000 members.

It is a lively community of developers and it is easy to find articles of interest as Azure, dotNET and C#.

https://dev.to/

DZone

DZone is another great resource for us. It boasts over 1 million members since being established in 2005. The site covers news, tutorials and tools for programming, web development and DevOps and is useful for all ranges of developer ability.

The site has a clean and well-categorised layout making it easy to dive into a specific area. The site offers a range of technical publications for free. This is a great way to become well-informed about a technology and gain insight into key industry trends.

https://dzone.com/

Channel 9

Channel 9 sounds like a TV channel, but is actually a Microsoft site hosting an abundance of tutorial and learning material. As we generally develop software using Microsoft technology, frameworks and tools, these videos are a great way for us to improve our knowledge.

https://channel9.msdn.com/

Conclusion

This is a cross section of the range of sites which we use at Innovensa to keep informed about the world of software development and technology. There are many other sites out there which we use alongside these and lots more that we simply don’t have time to use.

Using sites such as these is a great way for you to keep in touch with current technology and trends.

What sites do you use? Leave us a comment.

Comparison of Object Mapper Libraries

Jon Dodd — Wed, 19 May 2021 09:44:41 +0000

In this article we look at object to object mappers in C# .NET. Mappers solve the common problem of writing mundane and repetitive code when assigning values between objects. Three different mapping libraries are evaluated to give an idea of common themes and some differences which might be relevant for your development needs.

The mapping libraries AutoMapper, AgileMapper and Mapster have been used in a simple demo program to explore some simple mapping scenarios.

If this is a new area for you then hopefully you'll gain some knowledge from reading this article. Or perhaps you have been using the same object mapper for some time; should you consider an alternative?

What is an object mapper and what problem does it solve?

Object to object mapping is the process of assigning values from one object to another. This is common in a layered architectures, particularly those developed using an ORM framework such as Entity Framework Core. There can be many instances in application code where there is a requirement to translate data between the underlying entity model classes and data transfer objects (DTOs). Another case where object mapping is used is between DTOs, typically from a Web API to view model classes in MVC web application.

Mapping code is quite mundane and repetitive to write and a well adopted solution is to use a mapping library. Mapping libraries generally work by matching members in objects and through object graphs by using a set of conventions based on name and in some cases type too.

Benefits of using an Object Mapper

Solving the object to object mapping problem with a mapping library will make your life as a developer easier. Here are some direct benefits:

Not writing repetitive boring code
Smaller, cleaner codebase
Consistent naming of properties across codebase
It is a strategy which is well adopted by developers

Comparing Object Mapping Libraries

In this post each of the mapping libraries are compared for the following:

Popularity
Ease of use
Ease of configuration
Collections
Mapping and reverse mapping
Flattening and unflattening
Nested objects
Projections
Documentation

For this evaluation, a C# .Net Core 5 console application was used using EntityFramework Core and SqlLite database. It is a simplified model of a layered architecture and available on GitHub.

The project contains a simple service interface which provides a few basic scenarios to test such as a single-level object to object mapping, a two-level object mapping with an object containing a collection and a reverse mapping.

In the project code, the interface is implemented for each mapping solution. Also for good measure, the interface was implemented without using a mapper. This is the mundane code that we wish to remove by using a mapping library!

Mapping can get quite in-depth so not all use cases are covered, but this simple project is available and can be further extended to try out different things.

Object Mapping Libraries

Three object mapping libraries were compared: AutoMapper, AgileMapper and Mapster. There are a range of libraries to use, but here we have a very popular, quite popular and less well-known object mapping library for comparison.

AutoMapper

This is our current object mapper of choice. We decided to use AutoMapper on some recent projects due to its existing popularity and its use in Jon P Smith’s practical book Entity Framework Core in Action.

AutoMapper takes a low-configuration approach and is designed to be used in dependency injection scenarios such as in ASP.Net Core applications.

AutoMapper demands a configuration which can be divided into profiles and validated. The library can perform a scanning operation to include all profiles when the configuration is built. It creates an expression tree which can be inspected during debugging using an extension to view.

See: https://automapper.org/

AgileMapper

AgileMapper is a zero-configuration, highly-configurable object-object mapper with viewable execution plans.

Members are matched on a set of name and type rules. If the type doesn’t map, no extra config is required to prevent errors.

Execution plans are formed by creating an expression tree and compiling to a function, these are then cached. These plans can be cached upfront and also viewed. The execution plans can be validated during development.

The library also offers deep cloning, updating and merging amongst other useful features.

See https://github.com/agileobjects/AgileMapper

Mapster

Mapster is another zero-configuration object-object mapper that matches by name. Once more, it supports configuration that configuration can be validated.

It uses an extension method which is available on any object to perform the mapping operation. Another extension method provides a convenient way of passing in values at runtime during mapping.

Mapster boasts good performance according to its own GitHub project page and compares itself with other libraries favourably.

The code repo also provides a tool to create DTO classes and extension methods from entity classes which can generate code and save time.

https://github.com/MapsterMapper/Mapster

How Do They Compare

Popularity

In terms of current usage AutoMapper is by far the most popular and established mapping library from the three selected.

	AgileMapper	AutoMapper	Mapster
NuGet Version	1.8.0	10.1.1	7.2.0
Total Downloads	300k	150M	2.3M
Daily Average Downloads	100	39k	1k
GitHub Stars	375	8k	1.5k

* correct as of 2021-05-17

Ease of use

All three were simple to understand and to setup using NuGet. In terms of usability, Agile Mapper and Mapster were easier than AutoMapper as neither have a requirement for configuration.

Getting started is similar for all three libraries:

Install package
Have source and destination types to map
Create configuration (required for AutoMapper)
Create instance (required for AutoMapper)
Perform some mapping!

Agile Mapper and Mapster both offer a static API, something that AutoMapper removed in v9.

Mapster is slightly different to the other two as it provides an extension method for the mapping operation. This is a convenient feature and feels natural to use.

Ease of configuration

Despite working by convention, mapping configuration is required in most cases. A trivial example included in the code example is to map a source first name and last name to a single destination full name field. This was a straightforward exercise in all three using fluent syntax.

All libraries are designed to work with dependency injection with configuration that is created once as a start-up operation. This will provide the application with a compiled set of mappings leading to a performance gain.

Configuration can be easily loaded as all the libraries provide a way of scanning for configuration classes, which is especially useful in larger codebases.

All three support operations before and after mapping takes place. AgileMapper offers some additional extension methods to limit when this should be applied which is a nice feature.

Collections

AgileMapper seems to support more collection types than AutoMapper or Mapster. Both AgileMapper and Mapster also have Dictionary support too, but only for keys with a string type.

During the mapping process, both AutoMapper and AgileMapper initialised empty collections when no value was to be mapped. This behaviour is good practice as collections are expected to be initialised. Mapster didn’t do this and returned nulls as default behaviour.

Mapping and reverse mapping

All three libraries performed straightforward mapping based on matching names. They also performed reverse mapping, although AutoMapper required configuration for this to work.

Another test was to see the default behaviour for a mapping of a larger type into a smaller type, in this case an int to a byte.

All three libraries handled the situation differently.

AutoMapper threw a runtime exception, so this mapping had to be explicitly ignored.
AgileMapper ignored the mapping as it has more complex mapping rules.
Mapster actually performed a mapping and added an incorrect value to the destination member. This is easily preventable using the config to ignore the member.

As with everything, testing and exploring what is actually happening to data and validating configuration is essential.

Flattening

All three support flattening by convention without any special configuration when the destination names followed a simple pattern.

For example: source.Author.StarRating will map to dest.AuthorStarRating.

Nested objects

All three supported mapping an object graph without any additional configuration. AgileMapper has a dedicated Flattening API with some useful functions such as flattening an object to a dictionary or query string parameter list.

IQueryable Projections

All three support IQueryable projections. This is a convenient way to map an entity object directly to the destination DTO when working with EF Core.

They are all very similar except for AutoMapper which requires the config to be passed into the extension method.

The projection ensured only the required members were declared in the select statement. The code example includes SQL logging so that it possible to inspect the SQL that was generated.

Documentation

Each library has documentation, but AutoMapper and AgileMapper have the clearest and most comprehensive content. Mapster could improve in this area, but hey, this is open source!

A Note on Performance

This study didn’t aim to do a performance comparison. Mapster boasts of superior performance compared to AutoMapper due to its pre-compilation strategy. However, all the libraries work in a similar way using compiled expression trees which are then cached for future execution.

Conclusion

First of all, if you are writing manual object to object mapping code, then start using a mapping library! This will speed up your development leaving you with fewer lines of code to maintain. There is plenty of choice, but any of the three in this article are suitable candidates.

If you are looking for a quick way in, then out of these three AgileMapper gives you a no-fuss, zero-config start and you can start by using its static API.

After looking at AutoMapper, AgileMapper and Mapster, the conclusion is that they are all fairly similar. They all contain the key features required for object mapping tasks. There are subtle usage and configuration differences, but any of them should be fine in most cases.

AutoMapper’s enforced configuration leads to a good habit to define the configuration upfront, but the lack of a static API removes some versatility available in the other two libraries.

Mapster’s extension method approach is a natural way to map objects and their performance figures, if true, are a bonus, but there was an issue in the mapping that needed configuration to resolve.

AgileMapper seems to have a good set of rules for mapping with quality documentation and some useful features not available in the other libraries.

As mentioned previously, in all cases, take the time to validate and check the mapping configuration and be aware that convention-based mapping can lead to data errors in some cases.

These libraries are feature rich and this article has not covered everything they can do. If you want to find out more, then read the docs and feel free to use the demo project!

Thanks for reading this whistle-stop comparison of object mapping libraries.