DEV Community: Brian Schroer

Regular expression capture and replace examples

Brian Schroer — Mon, 26 Sep 2022 01:20:45 +0000

Regular expressions are incredibly powerful, but they're sometimes described as "looking like cartoon characters swearing", and the syntax can be difficult to remember.

I only find myself needing to write code to "capture" and replace values from a string a couple of times a year and always have to re-learn the syntax, so I'm blogging this for my reference. I hope it will be helpful to you also.

I'm including examples in JavaScript and C#...

Here's the scenario for the following examples: We want to log XML payment account setup requests/responses, but the request contains a bank account number:

<Name>Sparky's Bank Account</Name>
<BankRoutingNumber>123456789</BankRoutingNumber>
<BankAccountNumber>987654321</BankAccountNumber>

Bank account numbers are sensitive information, so we don't want to log them as-is.

Here's the basic Regex to find BankAccountNumber XML elements. The "\d+" (one or more digits) pattern defines the account number:

JavaScript

const regex =
    new RegExp('<BankAccountNumber>\\d+<\/BankAccountNumber>', 'g');

var regex = new Regex(
    @"<BankAccountNumber>\d+<\/BankAccountNumber>", 
    RegexOptions.Compiled);

...and code using the Regex to find the bank account XML elements:

JavaScript

const matches = requestXml.matchAll(regex);
console.log([...matches]);

foreach (Match match in regex.Matches(requestXml))
{
    Console.WriteLine(match.Value);
}

Results:

<BankAccountNumber>987654321</BankAccountNumber>

Replacing

Let's replace the bank account numbers with asterisks:

JavaScript

const censored = requestXml.replace(
    regex,
    '<BankAccountNumber>*********</BankAccountNumber>');

console.log(censored);

string censored = regex.Replace(
    requestXml,
    "<BankAccountNumber>*********</BankAccountNumber>");

Console.WriteLine(censored);

Results:

<Name>Sparky's Bank Account</Name>
<BankRoutingNumber>123456789</BankRoutingNumber>
<BankAccountNumber>*********</BankAccountNumber>

Capturing

A capture group is defined by enclosing part of the regex ("\d+" in this example) in parentheses:

<BankAccountNumber>(\\d+)<\/BankAccountNumber>

The entire match (the XML element in this example) is an automatic capture group, so this will result in two capture groups:

JavaScript

const matches = requestXml.matchAll(regex);
for (const match of matches) {
    const captures = [...match];
    for (var i = 0; i < captures.length; i++) {
        console.log(`[${i}] ${captures[i]}`)
    }
}

foreach (Match match in regex.Matches(requestXml))
{
    for (int i = 0; i < match.Groups.Count; i++)
    {
        Console.WriteLine($"[{i}] {match.Groups[i]}");
    }
}

Results:

[0] <BankAccountNumber>987654321</BankAccountNumber>
[1] 987654321

Named captures

You can name a capture group with the syntax "(?<name>pattern)". In this example, I'm using the name "acctNum":

<BankAccountNumber>(?<acctNum>\\d+)<\/BankAccountNumber>

(The angle bracket syntax for group naming is a bit confusing for this example because it looks like XML.)

Using a named capture:

JavaScript

const matches = requestXml.matchAll(regex);
for (const match of matches) {
    console.log(match.groups.acctNum);
}

foreach (Match match in regex.Matches(requestXml))
{
    Console.WriteLine(match.Groups["acctNum"].Value);
}

Results:

987654321

Replacing with a function

We shouldn't log account numbers, but let's say our security policy allows logging them "masked". Let's try replacing with a "callback" function that replaces all but the last four digits with asterisks:

JavaScript

const censored = requestXml.replaceAll(regex, match => {
    const innerMatches = [...match.matchAll(regex)];
    const acctNum = innerMatches[0].groups.acctNum;
    const len = acctNum.length;
    const masked = (len > 4)
        ? '*'.repeat(len - 4) + acctNum.substr(len - 4)
    : '*'.repeat(len);
    return `<BankAccountNumber>${masked}</BankAccountNumber>`;
});

console.log(censored);

string censored = regex.Replace(requestXml, match =>
{
    string accountNumber = match.Groups["acctNum"].Value;
    int len = accountNumber.Length;
    string masked = (len > 4) 
        ? new string('*', len - 4) + accountNumber.Substring(len - 4) 
        : new string('*', len);
    return $"<BankAccountNumber>{masked}</BankAccountNumber>";
});

Results:

<Amount>123.45</Amount>
<BankRoutingNumber>123456789</BankRoutingNumber>
<BankAccountNumber>*****4321</BankAccountNumber>

.Net "Fiddle" containing the C# code excerpted above

JS "Fiddle" containing the JavaScript code excerpted above

Sparky's Tool Tips: LINQPad

Brian Schroer — Wed, 10 Aug 2022 14:22:00 +0000

Of all my favorite tools, LINQPad is probably the favorite. I use it every day, several times per day.

LINQ

In 2007, Microsoft's .NET 3.5 introduced (L)anguage (In)tegrated (Q)uery, one of the killer features of .NET, and Joseph Albahari introduced LINQPad almost immediately afterward, providing the ability to do database queries using LINQ as an alternative to SQL.

Here's a screenshot from an early version of LINQPad (it still pretty much looks the same):

The screenshot above uses LINQ "query syntax", but of course, you can also use "method syntax" (.Where, .OrderBy). That's because LINQPad isn't just for LINQ and databases - It's for any any C#/F#/VB expression, statement block or program...

Code "scratchpad"

If you want to quickly try out some code, instead of creating a console app in Visual Studio, you can just open up LINQPad and and type a line or two...

I use it a lot for quick code experimentation, and have amassed a collection of tiny utility "program" queries in LINQPad (JSON and XML formatting, removing line feeds and tabs from strings, etc.), but working with databases is LINQPad's main claim to fame...

Database

As shown in the animation below that I "borrowed" from Jiří Petržilka's blog, if you query a table with foreign keys, LINQPad shows those relationships as navigation links to those entities:

Querying with LINQ is what LINQPad was created for, but you can also query with plain old SQL:

If you do query with LINQ, you can click the results "SQL" tab to see the SQL that was generated:

I almost never use SQL Server Management Studio for SQL queries any more.

Extensions, references & NuGet

You can reference .NET DLLs and NuGet packages and use them in your queries and create/save your own extension methods and classes and use them in your queries:

In this example query, the underlined code uses extensions I wrote to:

run the SQL Server query "WITH (NOLOCK)" (in a TransactionScope with IsolationLevel.ReadUncommitted, actually) so it doesn't tie up the table
convert from UTC time to my local time
format a column containing JSON with indentation

Pricing

There is a free version, which I'm ashamed to admit I used for probably thousands of hours before finally doing the right thing and sending some money Joseph's way.

There are several premium license versions starting at US $59, which add autocompletion & tooltips, code formatting, cross-database querying, etc.

Summary

I'm afraid this post doesn't adequately convey LINQPad's awesomeness. I've been using it for years, and keep discovering new capabilities (interactive regular expression editing & testing !?).

I urge you to give it a try.

You can learn more about LINQPad and download the installer from
https://www.linqpad.net/.

Sparky's Tool Tips: "Favorite Documents" Visual Studio extension

Brian Schroer — Thu, 29 Jul 2021 02:23:58 +0000

When you're working with a Visual Studio solution, even if it contains multiple projects and dozens of files, you usually spend most of your time working with a handful of documents.

The Favorite Documents Visual Studio 2019 extension adds a "Favorite Documents" menu to Visual Studio to make it easy to get to them.

When you're working with a file that you want to get back to easily later, just click the "Favorite Documents" toolbar's "⭐" icon:

...and click the popup dialog's "Add" button to add it to the favorites menu:

In this screenshot, I've added several favorite documents:

The second, "eight-pointed star" icon adds all open documents to your Favorite Documents, and the third icon can be used to add external documents.

Favorites are "remembered", so if you close a solution and come back to it later, the favorites will still be there.

By default, favorites are "Solution-specific" - they're tied to the solution's folder, so if you open another branch of the same solution you won't see the favorites.

If you don't check the "Solution-specific" checkbox when adding, the favorites are relative to the solution root, so they work across multiple branches. Here are my cross-solution favorites:

Two things I'd like to point out in the screenshot above:

You can add Source Control Explorer links as favorites
You can organize favorites in folders

The last icon on the Favorite Documents toolbar brings up the "Organize Favorites" window:

Sparky's Tool Tips: TFS Auto Shelve

Brian Schroer — Mon, 26 Jul 2021 21:02:40 +0000

This may be the most useful tool I've blogged about, and probably the simplest...

TFS Auto Shelve for Visual Studio is a Visual Studio 2019 extension that periodically shelves pending changes to Team Foundation System or Azure DevOps source control.

I can't count how many times I've used it to retrieve code files I've accidentally deleted, or files where I've started making changes and saved my mind and wanted to "roll back" to a previous version that hadn't been checked in.

You use the Visual Studio "Tools | Options | TFS Auto Shelve" menu to configure how often you want to shelve, how many shelvesets to keep, and how they should be named.

The name is defined using placeholders, and the default name is "Auto-{0}":

{0}: WorkspaceInfo.Name (machine name for me - I'm not sure if it's something different for other installations)
{1}: WorkspaceInfo.OwnerName
{2}: DateTime.Now
{3}: Domain of WorkspaceInfo.OwnerName
{4}: UserName of WorkspaceInfo.OwnerName

You can retrieve shelved files via the Visual Studio "File | Source Control | Find | Find Shelvesets" menu:

(I've used my incredible graphic skills😉 on the screenshot to block out information specific to the company where I work.)

You can see from the screenshot above that there were no shelvesets created overnight or over the weekend. Iit's smart enough to only create them while you're actively using Visual Studio.

The extension adds two items to the Visual Studio "Team" menu. The first shows you whether the extension is running, and the second lets you create an on-demand shelveset:

Sparky's Tool Tips: Moq.AutoMock

Brian Schroer — Mon, 26 Jul 2021 01:09:27 +0000

Probably the most important thing that makes .NET classes unit-testable is dependency injection (injecting interfaces, not implementations), usually via constructor injection.

Mocking libraries make it easier to generate "mock" interface implementations, and to verify that the interfaces were used as expected. Moq is the most popular .NET mocking library.

If you're using Moq, you may be interested in my SparkyTestHelpers.Moq and SparkyTestHelpers.MoqFluent NuGet packages. They provide an alternative to "It.IsAny" and "It.Is" syntax that I think is easier to write and read, and fluent assertions for verifications.

....lost of interfaces

The Moq.AutoMock NuGet package provides an "auto-mocker" container for Moq.

AutoMocker.CreateInstance<T> creates a new instance of the specified type, automatically generating Mocks for all of its constructor interface parameters. (The class must have a constructor where all of the parameters are interfaces):

Without AutoMocker:

var mockReader = new Mock<IReader>();
var mockFormatter = new Mock<IFormatter>();
var mockLogger = new Mock<ILogger>();
var foo = new Foo(
    mockReader.Object, mockFormatter.Object, mockLogger.Object);

With AutoMocker:

var autoMocker = new AutoMocker();
var foo = autoMocker.CreateInstance<Foo>();

To .Setup or .Verify mock behavior, you can get the auto-generated mock via AutoMocker's "GetMock<TMock>" method:

autoMocker.GetMock<IFormatter>.Setup(x =>
    x.Format(It.IsAny<decimal>()).Returns(x => x.ToString("###.00"));

You may find it advantageous to create a custom AutoMocker subclass for your project that sets up "happy path" behavior for some of your commonly used interfaces:

public class CustomAutoMocker : AutoMocker
{
    // constructor
    public CustomAutoMocker()
    {
        // Set up commonly used interfaces
        Mock<IFormatter> mockFormatter = GetMock<IFormatter>();
        //mockFormatter.Setup(x => ...
    }
}

    var autoMocker = new CustomAutoMocker();
    var foo autoMocker.CreateInstance<Foo>();
    // following tests will use Setups defined in the CustomAutoMocker

A custom AutoMocker subclass can also override the CreateInstance<T> method to perform additional logic when an instance of a specific type is created. For example, in a project using ApiControllers that I work on (which was not originally written with unit testing in mind), I detect construction of ApiController instances and automatically set up their .Request and .User properties:

public class CustomAutoMocker : AutoMocker
...
public new T CreateInstance<T>() where T : class
{
    T instance = base.CreateInstance<T>();

    var apiController = instance as ApiController;
    if (apiController != null)
    {
        // Set up ApiController's Request and User 
        apiController.Request = new HttpRequestMessage();
        apiController.Request.SetConfiguration(new HttpConfiguration());
        apiController.User = BuildClaimsPrincipal();
    }

    return instance;
}

private ClaimsPrincipal BuildClaimsPrincipal()
{
    // (code to build ClaimsPrincipal and
    // assign it to Thread.CurrentPrincipal)
}

Mock.AutoMock and a custom AutoMocker subclass have greatly reduced the amount of repetitive and tedious mock setup code I need to write in my unit tests.

If you're using Moq, I highly recommend it.

Sparky's Tool Tips: Customize Visual Studio Window Title / SolutionColor

Brian Schroer — Wed, 21 Jul 2021 11:50:20 +0000

If you're like me, you usually have multiple Visual Studio solutions open at the same time.

The main application I work on is an ASP.NET web site with a separate API back end site, so I usually have the web solution running in one Visual Studio instance and the API solution in another.

I also frequently work on multiple feature branches at once, so it's not uncommon for me to have three or four Visual Studio instances going.

When you do that, it can be confusing to tell which instance is which. These are two Visual Studio 2019 extensions that help...

SolutionColor

https://marketplace.visualstudio.com/items?itemName=Wumpf.SolutionColor

This one's really simple. It just adds a toolbar with buttons you can use to set the color of the title bar on a per-solution basis. Your color choice is "remembered" and re-applied every time you open the solution:

The "Pick title bar color" button pops up a color picker to choose a background color. A foreground color of black or white is automatically chosen - whichever is most readable against the background:

I usually choose a bright color for the web solution (since it's the up-front pretty solution), and a darker version of that color for the API solution:

Customize Visual Studio Window Title

https://marketplace.visualstudio.com/items?itemName=mayerwin.RenameVisualStudioWindowTitle

This extension, as you can probably guess from its name, customizes the Visual Studio window title.

Unlike previous Visual Studio versions, VS 2019 by default doesn't have a title bar in the app window. (You can enable it via the "Tools | Options | Environment | Preview Features | Use compact menu and search bar" menu.) The title is also displayed on Windows taskbar buttons, though.

Here's the default taskbar button title experience:

The extension allows you to use "tags" (e.g. "[solutionName]", "[parentPath]") to define how titles should be formatted:

There are a lot of tags you can use, and they're defined in the "Supported Tags" option window:

You can build different titles for design mode, running mode and break mode. I like to use "|" between solution name and parent path in design mode and emojis to simulate video player "play" and "pause" buttons in running and break modes:

design: [solutionName] | [parentPath]
running: [solutionName] ▶ [parentPath]
break: [solutionName] ⏸ [parentPath}

In addition to these default title formulas, you can set up titles for specific solutions, saved to either a file that lives with that solution or to a central "global" XML file:

I prefer the "global config". The global XML file contains "SolutionSet" elements where you define solution folders and names, and the title formulas to use for each:

Here are the results on my Windows taskbar. I can easily see that I have an API solution and web solution instance open, whether they're running or not, and the branch name for each:

Sparky's Tool Tips: Fancy Zones

Brian Schroer — Fri, 16 Jul 2021 23:13:05 +0000

Not strictly a developer tool, but devs usually have lots of app windows open at the same time, and I'm sure you'll find this useful.

...and when I say "windows" I mean Windows windows. There's probably something similar in the macOS world, but the last Apple product I used was a ][+, so I can't give you any advice about that.

Windows 10 has extremely basic support for window dragging and "snapping". If you drag a window off the side of the screen, you'll see a transparent overlay over that horizontal half of the screen and if you "drop" the window, it will snap/dock to fill half of the screen.

Fancy Zones, one of the Microsoft PowerToys utilities, lets you do something, well... fancier.

The Fancy Zones layout editor lets you define "drop zones". There are several default templates, but if you want to get "fancy", you create a custom layout:

If you have multiple monitors, you can set up different layouts on each.

When you're dragging a windows and press the Shift key, the drop zones light up, and if you drop the window onto a zone, it will snap to fill the zone. Here it is in action on my machine:

A developer can't be expected to work with a measly five screens😏, so I've got my wide monitors set up with side-by-side zones and my "portrait" left-side monitor set up with top and bottom zones so I can easily rock eight or nine docked windows at a time.

Fancy!

PowerToys also has a lot of other goodies:

Color Picker
File Explorer add-ons
Image Resizer
Keyboard Manager
PowerRename
PowerToys Run (a mini version of Wox - spoiler alert: Wox will be the subject of one of my future "favorite tools" posts.

P.S. I forgot to mention the price - There ain't one - It's free!

Sparky's Tool Tips: NimbleText

Brian Schroer — Wed, 14 Jul 2021 02:46:49 +0000

NimbleText is a Windows application, but if you're not on Windows or don't want to install something on your machine, there's an online version (albeit with fewer features).

I've been using NimbleText for about 15 years. (Actually, I started with Leon Bambrick's web site "The World's Simplest Code Generator", which eventually morphed into NimbleText.

The idea behind NimbleText is simple. You give it a delimited list of data and a substitution pattern, and it outputs resulting rows. Here's an animation from the NimbleText web site showing it being used to generate SQL statements:

Functions

That's enough for most of the text manipulation I need to do, but there are also several column manipulation functions that can be inserted via its "Functions" menu:

toUpperCase
toLowerCase
toTitleCase
toPascalCase
toCamelCase
toSentenceCase
toWords
reverse
replace
htmlEncode
htmlDecode
urlEncode
urlDecode
xmlEncode
xmlDecode
split
charAt
indexOf
lastIndexOf
slice
substr
left
right
lpad
rpad
dateFormat

Here's how much I rely on NimbleText - I just reflexively used the tool to help write this post about the tool. I used it to combine dashes and function names to create the Markdown for that bulleted list of functions!😲

You can save/load data and patterns to/from local files.

Pricing

It's free!

You can purchase a license for $19.95 USD that unlocks some additional features like:

"where" filters
sorting
snippet management

I used NimbleText and other similarly priced tools for years for free before realizing that it's a pretty small price to pay for something so valuable. Don't be like me - If there's a tool that makes your life easier, throw the developers a few bucks.

While writing this post, I came across some things I didn't know (or had forgotten) that NimbleText can do. I'm looking forward to trying them out.

Give NimbleText a try, I think you'll like it!

Sparky's Tool Tips: Fluent Assertions

Brian Schroer — Sun, 11 Jul 2021 14:20:53 +0000

I like writing unit tests more than the average developer (not saying much, I realize - Testing is something many devs... de-test 🥁).

I really appreciate tools that make it easier and more fun to write tests (in fact, I've written some myself), and Fluent Assertions is one of my favorites.

The Microsoft.VisualStudio.TestTools.UnitTesting Assert, StringAssert and CollectionAssert classes are... OK, I guess. (It's been a while since I used NUnit and I've never used xUnit, so I don't know about the built-in asserts in those frameworks.)

Fluent Assertions is a set of .NET extension methods that allow you to specify the expected outcome of a TDD or BDD-style unit test with a sentence-like syntax. For example, the "MSTest" syntax:

Assert.AreEqual(31, daysInJune);

...can be fluently expressed as:

using FluentAssertions;
. . .
daysInJune.Should().Be(31);

"Using" the "FluentAssertions" namespace enables a ton of useful "Should()" extension methods for:

strings:

Be(expected)
BeNull()
BeEmpty()
StartWith(expected)
EndWith(expected)
HaveLength(expected)
Contain(expected)
...

numbers:

Be(expected)
BeGreatorOrEqualTo(expected)
BeLessOrEqualTo(expected)
BeInRange(minimum, maximum)
BePositive()
...

DateTime:

Be(1.March(2022).At(22, 15))
BeOnOrAfter(1.March(2010))
HaveDay(1)
HaveMonth(3)
HaveYear(2010)
HaveHour(22)
BeLessThan(10.Minutes()).Before(otherDatetime)
...

collections:

HaveCount(expected)
HaveSameCount(otherCollection)
Contain(expected)
NotContain(expected)
OnlyContain(x => x.predicate)
...

These are just a few examples. There are dozens more methods for these and many other types.

And... assertions are chainable!

string stateName = "OHIO";
stateName.Should().StartWith("O").And.EndWith("O").And.Contain("HI");

Exceptions

I don't like the MS Test [ExpectedException(type)] attribute. Among other shortcomings, it doesn't let you test the exception message.

With Fluent Assertions, exception testing looks like this:

subject.Invoking(x => x.Foo("Hello"))
    .Should().Throw<InvalidOperationException>()
    .WithMessage("Hello is not allowed at this moment");

...or with "arrange / act / assert" syntax:

Action action = () => x.Foo("Hello");

action
    .Should().Throw<InvalidOperationException>()
    .WithMessage("Hello is not allowed at this moment");

Extensibility

Fluent Assertions is nicely set up to allow you to write your own "Should" extension methods.

There are many NuGet packages containing additional extension methods, including my own SparkyTestHelpers.Moq.Fluent.

But wait, there's more!

Fluent Assertions doesn't just give you better syntax for writing assertions - it gives you much better messages when an assertion fails, for example:

With Assert.AreEqual:

string correctNameSpelling = "Bryan";
Assert.AreEqual("Brian", correctNameSpelling);

...the failure message is:

Assert.AreEqual failed. Expected:<Brian>. Actual:<Bryan>.

With Fluent Assertions:

string correctNameSpelling = "Bryan";
correctNameSpelling.Should().Be("Brian");

..the failure message is:

Expected correctNameSpelling to be "Brian", but "Bryan" differs near "yan" (index 2).

The "differs near" and index are a bit of overkill for strings this short, but pretty handy for long strings!

(BTW, this is not a trivial example. correctNameSpelling SHOULD BE "Brian" and if your parents named you "Bryan", you should call them and complain.😏)

I like Fluent Assertions a lot, and if you're writing .NET unit tests, I think you .Should() give it a try!

Custom .NET XML .config sections with SparkyTools.XmlConfig

Brian Schroer — Wed, 07 Jul 2021 14:51:54 +0000

This article is about dying technology - .NET framework web.config and app.config XML files.

.NET Core overhauled application configuration, jettisoning .config XML files in favor of app settings JSON files, and .NET 5 brings those configuration changes back into "Framework" .NET.

For those of us who are still acting as caretakers for geriatric .NET framework apps using .config files though, here's a tool to make it a bit easier...

If you want to load configuration data for .NET application from a web.config or app.config section other than the built-in sections (e.g. appSettings, connectionStrings), you have to write a custom IConfigurationSectionHandler implementation to handle your custom .config section. It’s not hard to do, but it’s a fairly tedious coding exercise. What if you didn’t have to?...

SparkyTools.XmlConfig NuGet packages

SparkyTools.XmlConfig: for .NET framework v4.6 and above
- NuGet package
- Documentation
SparkyTools.XmlConfig.Fx: for .NET framework v4-4.5.1
- NuGet package
- Documentation

The code in these packages was inspired by a blog post called "The Last Configuration Section Handler I'll Ever Need" by Craig Andera that I read way back in 2003 🤯. I've been using this technique since then, and finally "NuGet-ed" it a few years ago.

ConfigurationSectionDeserializer / ConfigurationSectionListDeserializer

These SparkyTools.XmlConfig classes makes it easy to load a strongly-typed object (or IList of objects) from a custom web.config or app.config file section without having to write a custom IConfigurationSectionHandler implementation.

For the code examples below, I'll be using this incredibly realistic C# class definition:

public class Foo
{
    public string Bar { get; set; }
    public decimal Baz { get; set; }
}

In the .config file, register each custom section with a type of “SparkyTools.XmlConfig.ConfigurationSectionDeserializer” or
“SparkyTools.XmlConfig.ConfigurationSectionListDeserializer”:

<configuration>
  <configSections>
    <section name="Foo" type="SparkyTools.XmlConfig.ConfigurationSectionDeserializer, SparkyTools.XmlConfig" />
    <section name="FooList" type="SparkyTools.XmlConfig.ConfigurationSectionListDeserializer, SparkyTools.XmlConfig" />
  </configSections>

(If you're using the SparkyTools.XmlConfig.Fx package, the types/namespaces will be "...XmlConfig.Fx.Config")

In each registered custom section, specify the object type via the type attribute. Here's an single instance section:

<Foo type="FooNamespace.Foo, FooAssemblyName">
    <Bar>bar</Bar>
    <Baz>123.45</Baz>
</Foo>

...and a “list” section: (Note that "type" is the "single" instance type, not "IList..."):

<FooList type="FooNamespace.Foo, FooAssemblyName">
    <Foo>
        <Bar>bar1</Bar>
        <Baz>111.11</Baz>
    </Foo>
    <Foo>
        <Bar>bar2</Bar>
        <Baz>222.22</Baz>
    </Foo>
</FooList>

You can use XmlAttribute attributes in your class definitions to tell the serializers to get properties from XML attributes rather than child XML elements:

public class Foo
{
    [XmlAttribute("bar")]
    public string Bar { get; set; }

    [XmlAttribute("baz")]
    public decimal Baz { get; set; }
}

<FooList type="FooNamespace.Bar, FooAssemblyName">
    <Foo bar="bar1" baz="111.11" />
    <Foo bar="bar2" baz="222.22" />
</FooList>

To read from your custom .config section, just call the ConfigurationSectionDeserializer or ConfigurationSectionListDeserializer Load method, specifying the object type and the .config section name:

Foo foo = 
    ConfigurationSectionDeserializer.Load<Foo>("Foo");

IList<Foo> fooList = 
    ConfigurationSectionListDeserializer.Load<Foo>("FooList");

Dependency Injection

My SparkyTools.DependencyProvider NuGet package can be used to create DependencyProvider<T> instances for constructing classes with dependencies that aren't easily mockable. DependencyProvider<T> just has one method, "GetValue()", which returns a T instance.

Here's a class with a dependency of type "Foo" injected via a DependencyProvider:

using SparkyTools.DependencyProvider;

public class Qux
{
    private readonly Foo _foo; 

    public Qux(IDependencyProvider<Foo> fooProvider)
    {
        _foo = fooProvider.GetValue();
    }
}

The static ConfigurationSectionDeserializer.DependencyProvider and ConfigurationSectionListDeserializer.DependencyProvider
methods create DependencyProviders for loading data from custom .config file sections.

Here's code for creating an instance of the Qux class shown above, injecting the Foo dependency from a custom .config file section:

using SparkyTools.XmlConfig;
. . .
var qux = new Qux(
  ConfigurationSectionDeserializer.DependencyProvider<Foo>("Foo"));

AppSettings.DependencyProvider

A bit off this post's topic of custom .config file sections, but still in the general XML configuration topic - The static AppSettings.DependencyProvider() method can be used to make classes that get values via ConfigurationManager.AppSettings more unit-testable...

Consider this class:

public class Quux
{
    public void DoThing()
    {
        if (ConfigurationManager.AppSettings["featureEnabled"] == "true")
        {
            // Do that thang!
        }
    }
}

If you want to unit test it, you'll have to either have an app.config file with an appSettings section in your test project or have your test code do a static method call to set the value, e.g.:

ConfigurationManager.AppSettings["serviceUrl"] = "http://fakeurl";

...and doing static things in unit tests is always a bad idea.

Instead of using ConfigurationManager.AppSettings directly you can abstract your class to say "I need a function that returns configuration values for given keys":

public class Quux
{
    private readonly Func<string, string> _getAppSetting;

    public Quux(IDependencyProvider<Func<string, string> appSettingsProvider)
    {
        _getAppSetting = appSettingsProvider.GetValue();
    }

    public void DoThing()
    {
        if (_getAppSetting("featureEnabled") == "true")
        {
            // Do that thang!
        }
    }
}

SparkyTools.XmlConfig.AppSettings.DependencyProvider() creates a DependencyProvider<Func<string, string>>) that "wraps" ConfigurationManager.AppSettings, so you can use it in your "real code":

using SparkyTools.XmlConfig;
...
    var qux = new Quux(AppSettings.DependencyProvider());

...and "mock" the appSettingProvider dependency in your unit tests.

How to test C# private methods / SparkyTestHelpers.NonPublic

Brian Schroer — Sun, 21 Mar 2021 13:55:51 +0000

How do you unit test private (or internal or protected) methods, properties and fields?

The short answer, which you'll find if you do a web search for this question, is DON'T:

You can usually indirectly test the behavior of non-public members by testing the public members that use them. If you find yourself wanting to access non-public members from unit tests, it's a "code smell" that the class you're testing should be refactored to be testable.

...Sometimes, though - maybe just temporarily so you can get tests wrapped around "legacy code" that you'll eventually be refactoring out, accessing non-public members from unit tests is a pragmatic choice. Here's how to do it:

If you're using the "MSTest" (Microsoft.VisualStudio.TestTools.UnitTesting) framework, it has a PrivateObject helper that can be used to access non-public members:

PrivateObject privateObject = new PrivateObject(subjectUnderTest);

object response = privateObject.Invoke("PrivateMethodName", 3, 
"test", DateTime.Now);

If you're using a different test framework, or if you want to use easier syntax (to do this thing that I'm telling you not to do 🙂), you can the ".NonPublic()" extension method fluent syntax included in the SparkyTestHelpers.NonPublic NuGet package:

NuGet package | Source code | API documentation

// methods
subjectUnderTest.NonPublic().Method("PrivateMethod").Invoke();
subjectUnderTest.NonPublic().Method("PrivateMethodWithArgs").Invoke(3, "test", DateTime.Now);

object value1 = subjectUnderTest.NonPublic().Method("PrivateFunction").Invoke();
bool typedValue1 = subjectUnderTest.NonPublic().Method("PrivateFunction").Invoke();

object value2 = subjectUnderTest.NonPublic().Method("PrivateFunctionWithArgs").Invoke("test", 3, true);
bool typedValue2 = subjectUnderTest.NonPublic().Method("PrivateFunctionWIthArgs").Invoke("test", 3, true);

// properties
subjectUnderTest.NonPublic().Property("PrivateDateProperty").Set(DateTime.Now);
object value = subjectUnderTest.NonPublic().Property("PrivateDateProperty").Get();
DateTime typedValue = subjectUnderTest.NonPublic().Property("PrivateDateProperty").Get<DateTime>();

// fields:
subjectUnderTest.NonPublic().Field("_stringField").Set("test");
object value = subjectUnderTest.NonPublic().Field("_stringField").Get();
string typedValue = subjectUnderTest.NonPublic().Field("_stringField").Get<string>();

The examples above are for "instance" members. For accessing static members, use .StaticMethod, .StaticProperty and .StaticField:

DateTime dt = subjectUnderTest.NonPublic().StaticMethod("PrivateStaticFunction").Invoke<DateTime>("test", 5);
bool boolValue = subjectUnderTest.NonPublic().StaticProperty("StaticProperty").Get<bool>();
string stringValue = subjectUnderTest.NonPublic().StaticField("_staticField").Get<string>();

MsTest's PrivateObject has a lot of methods with binding flag, type array, CultureInfo, etc. arguments. I honestly don't know when those would be needed, but if you're unable to accomplish what you need to with the fluent syntax described above, you can use this package's SparkyTestHelpers.NonPublic.NonPublicMembers class. It's a "clone" of PrivateObject, and uses the same syntax.

SparkyTestHelpers: AspNetMvc

Brian Schroer — Fri, 28 Feb 2020 23:09:09 +0000

.NET Framework version:
NuGet package | Source code | API documentation

.NET Core version:
NuGet package | Source code | API documentation

These NuGet packages (one for the “classic” ASP.NET MVC Framework and one for ASP.NET Core MVC) contain helpers for testing that MVC controller actions return the expected results:

Controller Testers

ControllerTester<T> tests action methods of controllers that inherit from System.Web.MVC.Controller / Microsoft.AspNetCore.Mvc.ControllerBase.

ApiControllerTester<T> tests action methods of controllers that inherit from the .NET Framework System.Web.Http.ApiController class.

The general syntax is:

tester
    .Action(action selection expression)
    .When(optional code to "arrange" test conditions)
    .Expecting...(optional code to set up assert expectations)
    .Test...()

Examples

//ControllerTester:

    moviesControllerTester
        .Action(x => x.Index)
        .TestView();

    moviesControllerTester
        .Action(x => () => x.Details(3))
        .ExpectingViewName("Details")
        .ExpectingModel<Movle>(movie => Assert.AreEqual("Office Space", movie.Title))
        .TestView();

    moviesControllerTester
        .Action(x => x.Edit(testInvalidModel))
        .WhenModelStateIsValidEquals(false)
        .TestRedirectToAction("Errors");

    moviesControllerTester
        .Action(x => () => x.Edit(testValidModel))
        .WhenModelStateIsValidEquals(true)
        .ExpectingViewName("UpdateSuccessful")
        .TestRedirectToRoute("Home/UpdateSuccessful");

//ApiControllerTester:

   moviesApiControllerTester 
        .Action<IEnumerable<Movie>>(x => x.GetAllMovies)
        .Test(movies => Assert.AreEqual(100, movies.Count());

   moviesApiControllerTester 
        .Action(x => () => x.Get)
        .WhenRequestHasQueryStringParameters(new QueryStringParameter("id", 3))
        .TestOkNegotiatedContentResult<Movie>(movie => Assert.AreEqual("Office Space", movie.Title));

    moviesApiControllerTester
        .Action(x => () => x.Update(updateModel))
        .WhenModelStateIsValidEquals(false)
        .TestBadRequestResult();

    moviesApiControllerTester
        .Action(x => () => x.Update(updateModel))
        .WhenModelStateIsValidEquals(true)
        .TestOkResult();

Instantiation

ControllerTester<T> and ApiControllerTester<T> can be created either via their constructors:

var homeControllerTester = new ControllerTester<HomeController>(testHomeController);
var moviesApiControllerTester = new ApiControllerTester<MoviesApiController>(testMoviesController);

...or via CreateTester extension methods:

var homeControllerTester = testHomeController.CreateTester();
var moviesApiControllerTester = testMoviesController.CreateTester();

"Action" Methods

tester.Action methods use lambda expressions to specify the controller action to be tested. The expressions enable Intellisense completion when you "dot on" to the controller argument.

The syntax for parameterless actions is ".Action(controller => controller.actionName)", e.g. .Action(x => x.Index).

For actions with parameters, the syntax is ".Action(controller => () => controller.actionName(arguments))", e.g. .Action(x => () => x.Get(3)).

"When" methods

WhenRequestHasQueryStringParameters(string siteUrlPrefix, NameValueCollection queryStringParameters)
WhenRequestHasQueryStringParameters(NameValueCollection queryStringParameters)
WhenRequestHasQueryStringParameters(string siteUrlPrefix, params QueryStringParameter[] queryStringParameters)
WhenRequestHasQueryStringParameters(params QueryStringParameter[] queryStringParameters)

The WhenRequestHasQueryStringParameters methods (ApiControllerTester only) set up the controller's Request property with a RequestUri containing the specified parameters. If the siteUrlPrefix isn't specified (it usually won't matter in unit tests), the value "http://localhost" is used.

WhenModelStateIsValidEquals(bool isValid)

This method sets up the controller's ModelState for testing.

When(Action action)

This method can be used to "arrange" any conditions necessary for the test, e.g. setting up a mocked interface method.

"Expecting" methods (ControllerTester only):

ExpectingViewName(string expectedViewName)

ExpectingViewName sets up automatic validation when followed by TestView or TestPartialView

ExpectingModel<TModel>(Action<*TModel> validate*)

ExpectingModel sets up automatic model type and possibly content (the validate callback action is optional) validation when followed by TestView or TestJson.

"Test" methods - ControllerTester:

ControllerTester<TController> has several .Test... methods used to assert that the controller action returns the expected ActionResult implementation (The method name suffixes correspond to ...Result types (e.g. TestView tests ViewResult). There are methods for all of the standard result types, plus the generic TestResult<TActionResultType> method.

The validate "callback" actions, which can be used to validate the result contents, are optional:

TestContent(Action<ContentResult> validate)
TestEmpty(Action<EmptyResult> validate)
TestFile(Action<FileResult> validate)
TestJson(Action<JsonResult> validate)
TestPartialView(Action<PartialViewResult> validate)
TestRedirect(string expectedUrl, Action<RedirectResult> validate)
TestRedirectToAction(string expectedActionName, Action<RedirectToRouteResult> validate)
TestRedirectToRoute(string expectedRoute, Action<RedirectToRouteResult> validate)
TestView(Action<ViewResult> validate)
TestResult<TActionResultType>(Action<TActionResultType> validate)

"Test" methods - ApiControllerTester - for actions that return an IHttpActionResult:

There several .Test... methods used to assert that API controller actions return the expected IHttpActionResult implementation. There are methods for all of the standard result types, plus the generic TestResult<THttpActionResultType> method:

The validate "callback" actions, which can be used to validate the result contents, are optional:

TestBadRequestErrorMessageResult(Action<BadRequestErrorMessageResult> validate)
TestBadRequestResult(Action<BadRequestResult> validate)
TestConflictResult(Action<ConflictResult> validate)
TestCreatedAtRouteNegotiatedContentResult<T>(Action<CreatedAtRouteNegotiatedContentResult<T>> validate)
TestCreatedNegotiatedContentResult<T>(Action<CreatedNegotiatedContentResult<T>> validate)
TestExceptionResult(Action<ExceptionResult> validate)
TestFormattedContentResult<T>(Action<FormattedContentResult<T>> validate)
TestInternalServerErrorResult(Action<InternalServerErrorResult> validate)
TestInvalidModelStateResult(Action<InvalidModelStateResult> validate)
TestJsonResult<T>(Action<JsonResult<T>> validate)
TestNegotiatedContentResult<T>(Action<NegotiatedContentResult<T>> validate)
TestNotFoundResult(Action<NotFoundResult> validate)
TestOkNegotiatedContentResult<T>(Action<OkNegotiatedContentResult<T>> validate)
TestOkResult(Action<OkResult> validate)
TestRedirectResult(Action<RedirectResult> validate)
TestRedirectToRouteResult(Action<RedirectToRouteResult> validate)
TestResponseMessageResult(Action<ResponseMessageResult> validate)
TestStatusCodeResult(Action<StatusCodeResult> validate)
TestUnauthorizedResult(Action<UnauthorizedResult> validate)
TestResult<THttpActionResultType>(Action<THttpActionResultType> validate)

"Test" methods - ApiControllerTester - for actions that return an HttpResponseMessage:

The validate "callback" actions, which can be used to validate the result contents, are optional:

Test(Action<HttpResponseMessage> validate)

...calls controller action, validates HttpResponseMessage.StatusCode (if ExpectingHttpStatusCode(HttpStatusCode) has been called) and returns the HttpResponseMessage returned from the action.

TestContentString(Action<string> validate)

...calls controller action, validates HttpResponseMessage.StatusCode (if ExpectingHttpStatusCode(HttpStatusCode) has been called) and returns the HttpResponseMessage.Content string.

TestContentJsonDeserialization<TContent>(Action<TContent> validate)

Testing ASP.NET MVC Core RazorPages

PageModelTester<TPageModel>

ASP.NET MVC Razor Page PageModels have a lot in common with Controllers (they kind of combine the “C” and “M” of MVC), so the Razor PageModelTester has similar Action, When..., ExpectingModel and *Test... methods:

Test… methods assert that the PageModel action returns the expected IActionResult implementation. There are methods for many standard result types, plus the generic TestResult<TActionResultType> method:

TestContent((optional) Action<ContentResult> validate)
TestFile((optional) Action<FileResult> validate)
TestJsonResult((optional) Action<JsonResult> validate)
TestPage((optional) Action<PageResult> validate)
TestRedirectToAction(string expecteActionName, string expectedControllerName, object expectedRouteValues, (optional) Action validate)
TestRedirectToPage(string expectedPageName, (optional) Action<RedirectToPageResult> validate)
TestRedirectToRoute(string expectedRoute, (optional) Action<RedirectToRouteResult> validate)
TestResult<TActionResultType>((optional) Action<TActionResultType> validate)

The validate “callback” methods may be used for additional data assertions, beyond testing proper return types.

Examples:

var homeModel = new HomeModel(/* with test dependencies */);

var pageTester = new PageModelTester<HomeModel>(homeModel);

pageTester
    .Action(x => x.OnGet)
    .ExpectingModel(model => Assert.IsTrue(model.Foo))
    .TestPage();

pageTester
    .Action(x => x.OnPost)
    .WhenModelStateIsValidEquals(false)
    .ExpectingModel(model => 
        Assert.AreEqual(expectedErrorMessage, model.ErrorMessage))
    .TestPage();

pageTester
    .Action(x => x.Post)
    .WhenModelStateIsValidEquals(true)
    .TestRedirectToPage("UpdateSuccessful");

Testing ASP.NET MVC Core ViewComponents

The .NET Core framework for ASP.NET MVC has another nice new tool that "framework" MVC doesn't: ViewComponents, a powerful alternative to partial views.

The ViewComponent test helper classes have a lot of similarities with their Controller and Razor PageModel counterparts:

ViewComponentTester methods

Invocation methods

Similar to the ControllerTester and PageModelTester "Action" methods:

Invocation(synchronous Invoke method expression)
Invocation(async InvokeAsync method expression)

"When" methods

WhenModelStateIsValidEquals(bool isValid)

This method sets up the ViewComponent's ModelState for testing.

When(Action action)

This method can be used to "arrange" any conditions necessary for the test, e.g. setting up a mocked interface method.

Expecting methods

.ExpectingViewName(string expectedViewName) — used with .TestView
ExpectingModel<TModelType>(Action<TModelType> validate) — used with .TestView

Test methods

TestContent(Action<ContentViewComponentResult> validate)
TestHtmlContent(Action<HtmlContentViewComponentResult> validate)
TestView(Action<ViewViewComponentResult> validate)
TestResult<TViewComponentResultType>(Action<TViewComponentResultType> validate)
WhenModelStateIsValidEquals(bool isValid) — used to test conditional logic based on ModelState.IsValid

All validate “callback” actions shown above are optional.

Example code

using SparkyTestHelpers.AspNetMvc
. . .

new ViewComponentTester<FooViewComponent>()
    .Invocation(x => x.Invoke)
    .ExpectingViewName("Default")
    .ExpectingModel(model => Assert.IsTrue(model.Baz))
    .TestView();

new ViewComponentTester<FooViewComponent>()
    .Invocation(x => x.Invoke)
    .WhenModelStateIsValidEquals(false)
    .ExpectingViewName("Errors")
    .TestView();

new ViewComponentTester<BarViewComponent>()
    .Invocation(x => x.InvokeAsnyc)
    .TestView();

Testing Routing

These test helpers are only in the .NET Framework NuGet package. Routing has been rewritten for .NET Core, and I’ll have to figure out how to mock a bunch of different dependencies before I can add routing test helpers for .NET Core. It looks like Ivaylo Kenov has figured it out, so if you want to unit test ASP.NET Core routing now, I suggest you look at his GitHub repo.

RouteTester

RouteTester and RoutingAsserter provide methods to assert that a given relative URL maps to the expected RouteData.Values. The RoutingAsserter.AssertMapTo overloads provide multiple ways to specify the expected values…

RouteTester Constructors

public RouteTester((Action<RouteCollection> routeRegistrationMethod*)
public RouteTester(AreaRegistration areaRegistration)

using SparkyTestHelpers.AspNetMvc.Routing;
. . .
  var routeTester = new RouteTester(RouteConfig.RegisterRoutes);
  var areaRouteTester = new RouteTester(new FooAreaRegistration());

RouteTester Methods

.ForUrl(string relativeUrl) — creates a new ##RoutingAsserter## instance.

RoutingAsserter

Nethods

AssertMapTo(IDictionary<string, object> expectedValues)
AssertMapTo(object routeValues)
AssertMapTo(string controller, string action, (object id)) — id defaults to null
AssertMapTo<TController>(Expression<Func<TController, Func<ActionResult>>> actionExpression)
AssertRedirectTo(string expectedUrl, (HttpStatusCode expectedStatusCode)) — expectedStatusCode defaults to HttpStatusCode.Redirect (302)

Examples

routeTester.ForUrl("Default.aspx")
  .AssertRedirectTo("Home/LegacyRedirect");

// alternate syntaxes for asserting Home/Index routing:

routeTester.ForUrl("Home/Index")
  .AssertMapTo(new Dictionary<string, object> 
  {{ "controller", "Home" }, { "action", "Index" }, { "id", null });
routeTester.ForUrl("Home/Index")
  .AssertMapTo(new {controller = "Home", action = "Index"});
routeTester.ForUrl("Home/Index")
  .AssertMapTo("Home", "Index");
routeTester.ForUrl("Home/Index")
  .AssertMapTo<HomeController>(x => x.Index);

// alternate syntaxes for asserting Order/Details/3 routing:

routeTester.ForUrl("Order/Details/3")
  .AssertMapTo(new Dictionary<string, object> 
    {{"controller", "Order"}, {"action", "Details"}, {"id", 3});
routeTester.ForUrl("Order/Details/3")
  .AssertMapTo(
    new {controller = "Order", action = "Details", id = 3 });
routeTester.ForUrl("Order/Details/3")
  .AssertMapTo("Order", "Details", 3);
routeTester.ForUrl("Order/Details/3")
  .AssertMapTo<OrderController>(x => () => x.Details(3));

Happy Testing!