David Gardiner - Unit Testing

Verify.Cli - Snapshot testing without tests

2025-07-28T07:00:00.000+09:30

In my last post, I looked at using the Verify library to implement snapshot testing in .NET unit tests.

I've been doing quite a lot of 'DevOps' work in recent years, and a large part of that has involved creating and optimising build and deployment (CI/CD) pipelines. Not infrequently I've wanted to add a sanity check to a pipeline to ensure a file has the correct content. "Oh if only I could call Verify from my pipeline", I'd think.

If the file was in version control, I could sometimes fallback to relying on git diff to tell if the file had changed. But if it was a generated file that technique wouldn't work. Other file comparison tools (like regular diff) might help, unless you had things like timestamps or other elements in the file that you wanted to ignore for the comparison. This is all bread and butter for Verify.

And so I created Verify.Cli!

Verify.Cli

Verify.Cli is a command-line tool that uses Verify internally. But while Verify was originally written to be used in unit tests, it is possible to host it in a console application and get similar functionality. It can be used to perform snapshot testing on an individual file.

You can install Verify.CLI as a .NET global tool, or there's a Docker image so you can run it from a container.

Case study - feed.xml

I've recently rebuilt my blog using Astro. It generates a static website, but there is a challenge. Astro and the other libraries that are used to build my blog are updated frequently. It would be great to have confidence that those updates are not breaking the site. If it was a regular software application I could write some unit or integration tests. Given it generates static files, then the idea of snapshot testing some specific files would be helpful.

The feed.xml file is created when you run pnpm build in the dist folder. Here's part of it:

<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-AU" xmlns:media="http://search.yahoo.com/mrss/">
  <id>https://david.gardiner.net.au/feed.xml</id>
  <title type="html">David Gardiner</title>
  <updated>2025-07-26T10:39:59.564Z</updated>
  <subtitle>A blog of software development, .NET and other interesting things</subtitle>
  <generator uri="https://github.com/flcdrg/astrojs-atom" version="1.0.48">astrojs-atom</generator>
  <author>
    <name>David Gardiner</name>
  </author>
  <link href="https://david.gardiner.net.au/feed.xml" rel="self" type="application/atom+xml"/>
  <link href="https://david.gardiner.net.au/" rel="alternate" type="text/html" hreflang="en-AU"/>
  <entry>
    <id>https://david.gardiner.net.au/2025/07/azure-pipeline-template-expression</id>
    <updated>2025-07-14T08:00:00.000+09:30</updated>
    <title>Azure Pipelines template expressions</title>
    <link href="https://david.gardiner.net.au/2025/07/azure-pipeline-template-expression" rel="alternate" type="text/html" title="Azure Pipelines template expressions"/>
    <category term="Azure Pipelines"/>
    <published>2025-07-14T08:00:00.000+09:30</published>
    <summary type="html">
      <![CDATA[Template expressions are a compile-time feature of Azure Pipelines. Learn how they differ to custom conditions
and see some common examples of their usage.]]>
    </summary>
    <content type="html" xml:base="https://david.gardiner.net.au/2025/07/azure-pipeline-template-expression">
      <![CDATA[<p>In my <a href="/2025/06/azure-pipeline-conditionals">last post</a> I wrote about using custom conditions in Azure Pipelines to evaluate whether to skip a step, job or stage at runtime.</p>
<p>Sometimes we can do better though. With template expressions we can not just skip something, we can remove it entirely. We can also use it to optionally insert values in a pipeline (something you can't do with runtime custom conditions).</p>
<p>The important thing to remember is that template expression are a "compile time" feature. They can only operate on things that are available at compile time. <a href="https://learn.microsoft.com/azure/devops/pipelines/process/set-variables-scripts?view=azure-devops&amp;WT.mc_id=DOP-MVP-5001655">Variables set by scripts</a>, and <a href="https://learn.microsoft.com/azure/devops/pipelines/process/variables?view=azure-devops&amp;tabs=yaml%2Cbatch&amp;WT.mc_id=DOP-MVP-5001655#use-output-variables-from-tasks">task output variables</a> are two examples of things that are not available at compile time.</p>
<p>Compare these two Azure Pipeline runs. The first uses custom conditions to decided if the 'Publish Artifact' step is executed or not. Notice the 'Publish Artifact' step is listed, but the icon shown is a white arrow (rather than green tick)
<img src="https://david.gardiner.net.au/_astro/azure-pipelines-custom-conditions.Be6IaBQz_101Uki.webp" alt="Job showing a step 'Publish Artifact' that was conditionally not executed" /></p>
<p>If we use a template expression, then if it evaluates to false then the step is not even included in the job!</p>
<p><img src="https://david.gardiner.net.au/_astro/azure-pipelines-template-expressions.kRV13og-_2f5chf.webp" alt="Job without a 'Publish Artifact' step " /></p>
<p><a href="https://learn.microsoft.com/azure/devops/pipelines/process/template-expressions?view=azure-devops&amp;WT.mc_id=DOP-MVP-5001655">Template expressions</a> use the syntax <code>${{ }}</code></p>
<p>You can reference <code>parameters</code> and <code>variables</code> in template expressions. The latter are only variables that are defined in the YAML file and most of the <a href="https://learn.microsoft.com/azure/devops/pipelines/build/variables?view=azure-devops&amp;WT.mc_id=DOP-MVP-5001655">predefined variables</a>. (That page does list which variables can be used in template expressions, but you may need to scroll the page to the right to see that column!)</p>
<p>You can't reference variables that are created by scripts or anything else that is only available at runtime.</p>
<p>You can use <a href="https://learn.microsoft.com/azure/devops/pipelines/process/expressions?view=azure-devops&amp;WT.mc_id=DOP-MVP-5001655#functions">general functions</a> (the same ones we used previously with runtime Custom Conditions) in template expressions, as well as two special <a href="https://learn.microsoft.com/azure/devops/pipelines/process/template-expressions?view=azure-devops&amp;WT.mc_id=DOP-MVP-5001655#template-expression-functions">Template expression functions</a>.</p>
<h2>Common patterns</h2>

We run the Verify CLI against this file like this (after creating a verified directory )

verify --file ./dist/feed.xml --verified-dir verified

Because there is no existing verified/feed.xml.verified.xml file, the Verify library launches Beyond Compare (my diff tool of choice) and I can use it to create the verified file.

However if I rebuild the site again and re-run verify, it shows up a difference. It turns out that the <updated>2025-07-26T10:39:59.564Z</updated> line is updated each time! Happily Verify's scrubbers can handle timestamps like that.

If we were using Verify in a unit test, we'd configure this scrubber using VerifySettings.ScrubInlineDateTimes(). The equivalent for the command-line tool is --scrub-inline-datetime. If we run verify again using this:

verify --file dist/feed.xml --verified-dir verified --scrub-inline-datetime "yyyy-MM-ddTHH:mm:ss.fffZ"

We'll see that the scrubber has replaced the timestamp with a placeholder:

  <updated>DateTime_1</updated>

With that in place we can repeat the validation with subsequent builds and be sure that the file should be equivalent. If the comparison ever fails in the future then we can be pretty confident it's caused by a change in our logic or an update to one of the libraries.

Here's how I'm using Verify.Cli in a GitHub Action workflow:

- name: Setup .NET
  uses: actions/setup-dotnet@v5
  with:
    dotnet-version: 9.x

- name: Install Verify.Cli
  run: dotnet tool install --global Verify.Cli

- name: Verify
  run: |
    verify --file dist/feed.xml --verified-dir verified --scrub-inline-datetime "yyyy-MM-ddTHH:mm:ss.fffZ"

Case study - blog post

The other thing I was keen to keep an eye on was individual blog posts. Here's part of one:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <link rel="icon" href="/favicon.ico">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <meta name="generator" content="Astro v5.12.0">
    <link rel="canonical" href="https://david.gardiner.net.au/2025/07/azure-pipeline-template-expression">
    <meta name="description" content="Template expressions are a compile-time feature of Azure Pipelines. Learn how they differ to custom conditions
and see some common examples of their usage."><meta name="og:description" content="Template expressions are a compile-time feature of Azure Pipelines. Learn how they differ to custom conditions
and see some common examples of their usage."><meta name="og:title" content="Azure Pipelines template expressions"><meta name="og:type" content="article"><meta name="og:url" content="https://david.gardiner.net.au/2025/07/azure-pipeline-template-expression"><meta name="og:image" content="/_astro/azure-pipelines-logo.B45UakAg.png"><meta name="og:image:width" content="80"><meta name="og:image:height" content="80"><meta name="og:image:alt" content="Azure Pipelines logo"><script type="application/ld+json">{"@context":"https://schema.org","@type":"BlogPosting","mainEntityOfPage":{"@type":"WebPage","@id":"https://david.gardiner.net.au/2025/07/azure-pipeline-template-expression"},"headline":"Azure Pipelines template expressions","description":"Template expressions are a compile-time feature of Azure Pipelines. Learn how they differ to custom conditions\nand see some common examples of their usage.","image":"/_astro/azure-pipelines-logo.B45UakAg.png","author":{"@type":"Person","name":"David Gardiner","url":"https://david.gardiner.net.au/"},"datePublished":"2025-07-14T08:00:00.000+09:30"}</script>
    <title>Azure Pipelines template expressions</title>
    
  <link rel="stylesheet" href="/_astro/_slug_.CT3ttAlr.css"></head>
  <body>
    <header>
      <nav>
        <div class="nav-container" data-astro-cid-pux6a34n>

Most of that should be pretty stable. I tried a similar approach to what I used for feed.xml, and created a pull request then ran it in the GitHub Actions workflow... and it failed!

When I looked closer I realised that I've configured pull request build to use pnpm build --devOutput, whilst main branch builds just use pnpm build.

One difference with the former is that it adds an extra attribute to <img> elements - data-image-component="true". To be able to compare files we'll need to remove all instances of that.

Verify.Cli has the --scrub-inline-remove parameter that we can use for that. eg.

--scrub-inline-remove ' data-image-component="true"'

When Astro processes images, it does appear to generate pretty stable URLs, but just in case it might be best to exclude those as well. Here's a typical img tag:

<img src="/_astro/MVP_Logo_Horizontal_Preferred_Cyan300_RGB_300ppi.a-4xiaYx_2bYEEr.png"

These are not fixed strings - they are unique for each image, so using a regular expression would make sense. This time we'll use --scrub-inline-pattern with an appropriate expression:

--scrub-inline-pattern '(?<prefix>")/_astro/[^"]+(?<suffix>")'

This parameter has an extra feature that I'm taking advantage of. If you include named groups in the regular expression 'prefix' and or 'suffix', then the scrubber will add those back to the start and end. I'm using that so that the double quotes are maintained.

The replacement looks like this:

<img src="STRING_5"

Here's the full command:

verify --file dist/2025/07/azure-pipeline-template-expression.html --verified-dir verified --scrub-inline-pattern '(?<prefix>")/_astro/[^"]+(?<suffix>")' --scrub-inline-remove ' data-image-component="true"'

In this case, the GitHub Action workflow is using the Docker image to run Verify.Cli (another way of using it instead of installing it as a .NET global tool):

- name: Verify post
  run: docker run --rm --user "$(id -u):$(id -g)" -v $PWD:/tmp flcdrg/verify-cli --file /tmp/dist/2025/07/azure-pipeline-template-expression.html --verified-dir /tmp/verified --scrub-inline-pattern '(?<prefix>")/_astro/[^"]+(?<suffix>")' --scrub-inline-pattern '(?<prefix>title=")[^"]+(?<suffix>")' --scrub-inline-remove ' data-image-component="true"' --scrub-inline-pattern '(?<prefix>meta name="generator" content="Astro v)[\d\.]+(?<suffix>")' --verbosity detailed

What if it fails?

If Verify.Cli fails locally on your machine, you can quickly identify the conflict via your visual diff tool of choice. But if it fails in a pipeline, then currently all you get is an error that the files are different. For now, I've come up with a hacky workaround:

- name: Diff files if error
  if: failure()
  run: |
    diff -u dist/feed.xml verified/feed.xml.verified.xml

This step in the workflow only runs if the Verify.Cli step failed. It assumes you have the diff tool installed on your build agent. This could be an aspect to improve in Verify.Cli in the future.

Conclusion

Take a look at https://github.com/flcdrg/astro-blog-engine for a repo making use of Verify.Cli (including the main workflow).

If you have a need to use the snapshot testing technique on individual files outside of unit tests, please give Verify.Cli a go. Let me know in the comments what you think, and feel free to submit any suggestions or bug reports over at the repo.

Helmet by Leonidas Oikonomou from Noun Project (CC BY 3.0)

Snapshot testing .NET code with Verify

2025-07-21T20:00:00.000+09:30

Snapshot testing has become a really popular way of asserting data has the correct shape and values in software unit tests. My first introduction to these kinds of tests was with ApprovalTests for .NET. You may also have encountered them in JavaScript with Jest. But in my opinion the standout library for snapshot testing is Simon Cropp's excellent Verify.

I've written previously about Verify, specifically an extension I created for Verify to facilitate snapshot testing with MongoDB. One thing that sets Verify apart is the ability to customise and configure how it works for each test, particularly in the way it serialises and sanitises/scrubs the data.

Data scrubbing (see Scrubbers) is how you deal with values that may change between unit test runs, but within a run they must be consistent. You can choose to either remove values entirely, or replace them with special placeholders.

For example, consider the following C# code that creates a dynamic JSON object:

var json = new
{
    id = Guid.NewGuid(),
    time = DateTimeOffset.Now,
    name = "David Gardiner",
    currentUser = Environment.UserName
};

var text = System.Text.Json.JsonSerializer.Serialize(json);

var settings = new VerifySettings();
settings.ScrubUserName();

// Ensure received and verified files have .json suffix (otherwise it will be .txt)
settings.UseStrictJson();

return VerifyJson(text, settings);

The actual value of the JSON object will change every time the code is run, as it includes values like a random GUID, the current date and time, and the current username. If you just compared a file that you'd serialised this object to, then it wouldn't match if you compared it again a few seconds later.

Instead, by the use of scrubbers and sanitisers, you end up with a file like this:

{
  "id": "Guid_1",
  "time": "DateTimeOffset_1",
  "name": "David Gardiner",
  "currentUser": "TheUserName"
}

Notice that the GUID, time and current user values have all been replaced with placeholders names. The clever thing is that if you had other properties with the same original values, then Verify is smart enough to swap those all over too (so you could easily confirm that Guid_1 was used in all the right places).

This means that your test will continue to pass if you run it 5 seconds later, or if you run it on a build server on the other side of the world with a different process username.

The underlying values will have changed, but the shape and usage of them hasn't, and that's what you care about.

There's a default set of scrubbers and sanitisers that you get out of the box, but you can enable additional ones or write your own. In the example above I opted in to username scrubbing by calling ScrubUserName().

If necessary, you can adjust how Dates and GUIDs are handled. There's even more options in Serializer Settings and Scrubbers.

Snapshot tests dramatically simplify your unit tests - the alternative would be lots of specific property asserts, which can get pretty messy.

The other aspect of Verify that really shines is how it can integrate with any of a number of popular GUI diff tools when you're running it interactively and a comparison fails.

In that scenario, it will automatically launch your diff tool (Beyond Compare is my diff tool of choice) showing you the actual and expected (verified) text and you can easily identify if the failure represents a bug that needs to be fixed, or alternatively it might be an expected change so you can easily update the verified content.

It's worth noting that Verify is smart enough to realise when it is running non-interactively (like on a build server), and in that case it just reports the comparison failed, causing the related unit test to fail. No GUI diff tools are launched.

In my next post I'll show how I took Verify and found a way to use it outside of unit tests.

Side note: The code samples in this blog post were included by using one of Simon's other projects - https://github.com/SimonCropp/MarkdownSnippets. A really clever tool for embedding code samples in Markdown files, which has the advantage that the code samples are more likely to be valid code as you can compile the original source files

Helmet by Leonidas Oikonomou from Noun Project (CC BY 3.0)

Snapshot testing Verify.MongoDB

2022-03-31T08:00:00.000+10:30

Verify is a snapshot tool created by Simon Cropp. It takes inspiration from ApprovalTests and makes it easy to assert complex data models and documents (e.g. as part of a unit test).

What I like about this technique is that if the data model or document is different to what the test expects, then not only does the test fail, but for local development, it can automatically launch familiar diff tools. One of my favourites is Beyond Compare, and it makes it very easy to identify what the actual differences are.

In addition to the main Verify library, Simon and others have also created extension packages to provide additional support for more specific cases (like Verify.AspNetCore, Verify.EntityFramework, Verify.ImageSharp, Verify.NServiceBus and more).

I was doing some work with Azure Cosmos DB using the Mongo API with .NET and thought it would be useful to be able to write some tests to capture what actual queries are being sent over the wire.

I'd recently listened to an episode of The Unhandled Exception podcast where Dan Clarke interviewed Simon on Snapshot Testing. He gave the example of using the Verify.EntityFramework extension package to write unit tests that would validate the SQL that Entity Framework was generating.

This made me wonder if I could do something similar for MongoDB. After reviewing how the Verify.EntityFramework extension worked, I took a closer look at the MongoDB .NET Driver library to see what hooks were available. After a bit of trial and error, I figured out how it was possible!

You can write a unit test that includes code like this:

MongoDBRecording.StartRecording();

await collection.FindAsync(Builders<BsonDocument>.Filter.Eq("_id", "blah"),
    new FindOptions<BsonDocument, BsonDocument>());
    
await Verifier.Verify("collection");

The verified file would have the following content:

{
  target: collection,
  mongo: [
    {
      Database: VerifyTests,
      Document: {
        filter: {
          _id: blah
        },
        find: docs
      },
      Type: Started,
      Command: find,
      StartTime: DateTimeOffset_1,
      OperationId: Id_1,
      RequestId: Id_2
    },
    {
      Document: {
        cursor: {
          firstBatch: [],
          id: 0,
          ns: VerifyTests.docs
        },
        ok: 1.0
      },
      Type: Succeeded,
      Command: find,
      StartTime: DateTimeOffset_2,
      OperationId: Id_1,
      RequestId: Id_2
    }
  ]
}

That's a representation of what would be sent over the wire by the query in the test. It's an ideal opportunity to confirm that the query is doing what you intended. For pay-per-use services like Cosmos DB, it's critical that your queries are as efficient as possible. Otherwise, it might cost you too much, and your queries might end up rate-limited.

After confirming it worked as I'd hoped, I figured it could be something that others might find useful, so I created a NuGet package. I got in touch with Simon to find out how best to get it published on nuget.org. He was most helpful, and I'm pleased to report that the package is now available at https://www.nuget.org/packages/Verify.MongoDB/, and the source repository is at https://github.com/flcdrg/Verify.MongoDB.

If you're building an application that's using the MongoDB .NET Driver then this package will help you create some useful snapshot tests.

Check it out!

The case of the disappearing 'Debug' CodeLens in Visual Studio Code

2020-11-10T12:00:00.000+10:30

Or how to debug any Jest unit test in Visual Studio Code

I'm trying to debug a TypeScript unit test which uses the Jest library. There's a nice VS Code extension vs-jest that integrates with Jest and even adds CodeLens labels so you can click to debug a specific test. Except the debug label kept disappearing! It would show when I first loaded the folder in Code, but after the tests all ran then the label would go away. Even though the test is passing, I wanted to debug it so I could step through the code. What's going on?

There's some troubleshooting tips listed on the vscode-jest README. This gave me the hint that there are some config settings that can alter how the extension behaves. When I viewed my current settings.json, I saw this:

{
    "typescript.tsdk": "node_modules\\typescript\\lib",
    "eslint.packageManager": "yarn",
    "eslint.validate": [
        "javascript",
        {"language": "typescript", "autoFix": true }
    ],
    "jest.debugCodeLens.showWhenTestStateIn": [
        "fail",
        "unknown"
    ]
}

That last setting caught my attention. Clicking inside that array and code completion offered two other values "pass" and "skip".

    "jest.debugCodeLens.showWhenTestStateIn": [
       "pass",
       "skip",
        "fail",
        "unknown"
    ]

Adding those and hitting save, and then the 'debug' labels returned and stayed for all the tests!

Unit Test Fixtures

2017-12-01T21:27:00.000+10:30

Almost ten years ago, I bought and read Gerard Meszaros’ xUnit Test Patterns, Refactoring Test Code. It is very comprehensive and seeks to document all the common test design patterns. Meszaros uses italics to indicate named patterns, and I'll follow that convention here.

The unit test framework I’ve used the most with .NET is NUnit. One quirk that I’m just beginning to understand better is the difference between Testcase Class and Fixture.

My confusion lies with how NUnit requires that classes which contain test methods, be decorated with the TestFixture attribute. I always assumed that this meant the class was "the fixture", but no!

Meszaros defines them as follows:

(I) use ‘test fixture’ or just ‘fixture’ to mean ‘the pre-conditions of the test’ and Testcase class to mean ‘the class that contains the Test Methods and any code needed to set up the test fixture’. (xUnit Test Patterns p.59)

The key thing is that while NUnit defaults to the Testcase Class per Fixture, you can do things differently.

Take a look at one of the unit test projects from the Cake project.

Notice how they’ve separated the Fixture classes and the Testcase classes into separate folders.

Here’s one of the test methods from the NuGetPackageInstallerTests class. Note how concise and uncomplicated it is. You can look at this method and very quickly understand what it’s testing.


[Fact]
public void Should_Be_Able_To_Install_If_Scheme_Is_Correct()
{
    // Given
    var fixture = new NuGetPackageInstallerFixture();
    fixture.Package = new PackageReference("nuget:?package=Cake.Core");

    // When
    var result = fixture.CanInstall();

    // Then
    Assert.True(result);
}

Now let’s look at the fixture class – NuGetPackageInstallerFixture

internal sealed class NuGetPackageInstallerFixture
{
    public ICakeEnvironment Environment { get; set; }
    public FakeFileSystem FileSystem { get; set; }
    public IProcessRunner ProcessRunner { get; set; }
    public INuGetToolResolver ToolResolver { get; set; }
    public INuGetContentResolver ContentResolver { get; set; }
    public ICakeLog Log { get; set; }

    public PackageReference Package { get; set; }
    public PackageType PackageType { get; set; }
    public DirectoryPath InstallPath { get; set; }

    public ICakeConfiguration Config { get; set; }

    public NuGetPackageInstallerFixture()
    {
        Environment = FakeEnvironment.CreateUnixEnvironment();
        FileSystem = new FakeFileSystem(Environment);
        ContentResolver = Substitute.For<INuGetContentResolver>();
        Log = Substitute.For<ICakeLog>();
        Config = Substitute.For<ICakeConfiguration>();

        ToolResolver = Substitute.For<INuGetToolResolver>();
        ToolResolver.ResolvePath().Returns(new FilePath("/Working/tools/nuget.exe"));

        Package = new PackageReference("nuget:https://myget.org/temp/?package=Cake.Foo&prerelease&version=1.2.3");
        PackageType = PackageType.Addin;
        InstallPath = new DirectoryPath("./nuget");

        ProcessRunner = Substitute.For<IProcessRunner>();
        ProcessRunner.When(p => p.Start(Arg.Any<FilePath>(), Arg.Any<ProcessSettings>()))
            .Do(info => FileSystem.CreateDirectory(InstallPath.Combine(Package.Package.ToLowerInvariant()).Combine(Package.Package)));
    }

    public void InstallPackageAtSpecifiedPath(DirectoryPath path)
    {
        ProcessRunner.When(p => p.Start(Arg.Any<FilePath>(), Arg.Any<ProcessSettings>()))
            .Do(info => FileSystem.CreateDirectory(path));
    }

    public NuGetPackageInstaller CreateInstaller()
    {
        return new NuGetPackageInstaller(FileSystem, Environment, ProcessRunner, ToolResolver, ContentResolver, Log, Config);
    }

    public IReadOnlyCollection<IFile> Install()
    {
        var installer = CreateInstaller();
        return installer.Install(Package, PackageType, InstallPath);
    }

    public bool CanInstall()
    {
        var installer = CreateInstaller();
        return installer.CanInstall(Package, PackageType);
    }
}

As described in xUnit Test Patterns, this Test Fixture has everything we need in place to exercise the SUT (system under test). It instantiates both the SUT and all its dependencies, and also provides helper methods that are called by the Test Methods. Without this, all of the setup and configuration code would have lived in the Testcase class (NuGetPackageInstallerTests). This looks like an example of the Transient Fresh Fixture pattern.

If you want to get another perspective on using test fixtures, I’d also recommend taking a look at Mark Seemann’s Advanced Unit Testing course on Pluralsight.

DDD Melbourne 2016

2016-08-20T19:58:00.001+09:30

Last weekend I was privileged to be able to attend my second DDD Melbourne conference. I flew over Friday afternoon and had an uneventful transit from Melbourne airport to the motel, via the Skybus and a train connection. I stayed locally near Monash University’s Caufield campus, the venue for this year’s event.

Around 350 people were there. Monash was a great venue, with all lecture theatres having excellent AV facilities, so no problems watching presentations or hearing speakers. It was also really nice to catch up with a few familiar faces.

The day started with a thought-provoking keynote from Paul Fenwick, making us stop and think about what kind of future we’re creating. That slide with the strange robots – I had that book as a child! 😀

After that I caught the following sessions:

Thinking in React with Mohammad Helmy
Deploying Straight to Production: A Guide to the Holy Grail with Damian Brady
The Actor/Model pattern in .NET: Akka.Net vs Orleans for the curious with William Tulloch
Better APIs with GraphQL with Josh Price

After lunch I also got to present 10 tools and libraries to enhance .NET Unit Testing.

The final talk for the day was from Shawn Wildermuth. An inspiring and personal look into the life of a developer, and a great way to end the day.

One key point Shawn made was how critical it is if you want to be a good developer, is to really work in your listening skills – not just “hearing” but actual ‘active listening’, because as it turns out, good communication skills are more important that good technical skills.

And with that DDD Melbourne was over for another year. Off to the airport for the flight back home late Saturday night to be back at home with family and my own bed.

Testing for Exceptions with NUnit

2014-11-20T21:21:00.001+10:30

I’ve been aware for a long time usual way of writing a unit test with NUnit that expects an Exception to be thrown is to use the ExpectedExceptionAttribute on the test method.

[ExpectedException(typeof(ArgumentException)] [Test] public void Test() { var sut = new ThrowUp();

sut.DodgyMethod(3);

}

I hadn’t noticed that around the release of NUnit 2.5, an alternative was added. The Assert.Throws method allows you to be specific about which bit of code in the test should be throwing an exception.

public void Test() { var sut = new ThrowUp();

Assert.Throws<ArgumentException>( () => sut.DodgyMethod(3) );

}

I think it’s a good improvement, and makes it a bit clearer where the exception should be coming from.

Unit testing your Silverlight/WP7 code with Portable Library Tools?

2011-01-20T10:54:00.001+10:30

I'm slowly improving my knowledge of developing in Silverlight and specifically apps for Windows Phone 7. My Internode Usage app has been out for almost a month, and I'm working on an update for that (including real Internode logos now that I've got permission). I've also been creating a new app that will display the nearest public toilet (particularly useful for parents of young kids, especially if you're travelling). That's been fun as I've got to use the Map control. I hope to publish that soon.

One thing I have missed was the ability to easily write unit tests for the code. The problem is that the code doesn't run on your desktop, it runs in the emulator or on a device. This has meant that most of the solutions so far have relied on running the test runner on the device as a separate application. That is certainly a valid way to test, but getting the results of the test back out isn't easy. Justin Angel describes one approach using the CoreCon API to read and write to the test app's Isolated Storage. Another way might be to get the test runner app to push the results back out to some kind of HTTP listener running externally to the emulator.

Enter the Portable Library Tools add-in. Just released as a CTP, this allows code to be targeted at both Windows Phone 7 and the regular CLR (as well as Silverlight and XNA) without having to jump through lots of hoops.

It should now be possible to create a regular .NET unit testing assembly (say using MbUnit with the Gallio test runner) and run tests over most of your code, and then just recompile to have the same code be deployed to WP7.

There will be exceptions, as you may need to refactor your code to extract out specific WP7 dependencies (that obviously have no equivalent in the desktop .NET Framework), but this looks like a promising step forward.

One caveat is that to install the Portable Library Tools, you need to have installed VS 2010 SP1 Beta. I'm being more careful about keeping my work laptop (which has also become my main dev machine) in good working order, so I'll be installing the SP1 beta on a separate VM just to be safe.

I'll do a follow-up post with my experiences. It might take a few days, as tomorrow I'm off riding in the Tour Down Under (again!), and might need a day or two to recover!

The art of Unit Testing with Examples in .NET

2009-07-14T22:49:00.001+09:30

The Art of Unit Testing: with Examples in .NET by Roy Osherove

I recently bought a copy of The Art of Unit Testing: with Examples in .NET by Roy Osherove, taking advantage of a discount being offered by Manning.

Already owning xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series) by Gerard Meszaros and Working Effectively with Legacy Code (Robert C. Martin Series) by Michael Feathers, I was interested to see what new insights Osherove would bring, especially as he would be focussing purely on the .NET platform (code samples are in C#).

The book is divided into 4 sections.

Part 1 (which I skimmed through) was an introduction to unit testing. Osherove uses NUnit for his examples which is reasonable considering it is probably the most popular unit testing framework for .NET at the moment.

His preferred naming convention for test methods is interesting – "[MethodUnderTest]_[Scenario]_[ExpectedBehaviour]". It contrasts with the "natural sentence" style I currently favour (which I'd trace back to Jean-Paul Boodhoo's unit testing episodes on dnrTV).

He also recommends naming test classes with a "Tests" suffix. I've always used the singular "Test", but I take his point that each test class does contain multiple tests so plural may be more accurate.

Part 2 introduces stubs, mock objects and isolation frameworks (aka mock object frameworks). Following a poll held on Osherove's blog, Rhino Mocks was chosen to demonstrate how a framework can simplify creating mock objects. I could be wrong, but you almost get a sense that this was done somewhat grudgingly considering Osherove himself works for TypeMock (who sell a commercial mocking framework). Curiously whilst including a link to the Rhino Mocks download site, he doesn't even mention Ayende's name at all.

Osherove makes the following recommendations about stubs and mocks:

Use nonstrict mocks when you can
Use stubs instead of mocks when you can
Avoid using stubs as mocks

I found this interesting, as we've been writing a lot of unit tests lately, and one of the things we're coming to realise is that brittle tests can be annoying. Tests that still test your code, but are more flexible about exactly how the code under test works (rather than setting strict expectations for each and every method call) are going to be more useful and less effort to maintain.

Part 3 looks at various strategies for organising tests and a number of patterns and anti-patterns to follow when creating tests.

Part 4 covers how to make unit testing the norm in an organisation, and how to work with legacy code.

Having some experience writing unit tests, I did find this book a bit light on. Osherove references Meszaros and Feather's books regularly. I would also consider both of these works cover the topic in a more detailed and thorough manner. However they are probably not necessarily as good a starting point for someone new to unit testing, especially someone who's main experience lies in developing for the .NET platform.

I finished the book surprisingly quickly – pleased that I'd learned a few new things, but left feeling that it would have been nice to learn a few more.

Tracing and logging WPF

2009-06-22T08:00:00.000+09:30

Whilst researching unit testing WPF applications I came across Bob King's answer to this question on StackOverflow.

WPF DataBinding can appear to be a bit of a mysterious black box, but I now know that you can enable diagnostic trace sources to see what's happening under the covers. Mike Hillberg shows some examples in this post.