Lars-Erik's blog

More efficient integration tests with Umbraco

Tue, 25 Nov 2025 07:11:08 Z

TLDR;

I made a package that removes the "database and Umbraco instance" per fixture constraint from Umbraco's Integration Test library. It also enables reuse of seeded database snapshots to avoid executing the same setup / seeding over an over per fixture or test.

An itch

I've spent way too long waiting for similar setup code for my integration tests the last couple of years. The modern .NET version of Umbraco's integration test library is super nice, and real effective with SQLite. But it's got a few constraints:

All things Umbraco is instantiated and spun up per test, granted a configurable amount.
Databases have to be "installed" and seeded for each TestFixture at the least.
All test fixtures need to inherit from Umbraco's base classes

So we spend a long time waiting for suff, even if it's only the little green box we care about:

We're also stuck either juggling a singleton of some sorts and/or stuffing a lot of "units" into the same fixture.
Any notion of intermediate base classes quickly become a sore spot.

An idea

I had recently discovered, likely for the n-th time in my life, that NUnit supports namespace scoped setup fixtures. Those live as long as all that other tests in that namespace and deeper. They bring an opportunity to share initial state across several fixtures. I often find it nice to have several fixtures for the same systems under tests because it makes sense to group by use-case rather than tech.

So I set out to see if I could hack together something that made Umbraco's base tests possible to use as setup fixtures rather than "base" fixtures. As things would have it it was early october, and the CanCon gang hosted a virtual hackathon on a friday. I took the day "off" regular work and gave it a go.

Dark magic

In the end I've used all the dirty tricks you can imagine in today's .NET landscape. You'll find Lib.Harmony for messing with Umbraco's tests' IL (Intermediate Language), and there's Castle DynamicProxy doing a lot of fooling around with the NUnit test hierarchy. The Harmony bit can likely be removed by making a few slight changes to Umbraco's test core, but I wanted to get this working satisfactory before suggesting such changes.

The bottom line is that those two tools let us run code before, after or even instead of inherited code. And that in turn enables all the following features.

A new way of composing tests

With the package I've cooked together we can leave the dark world of peach and purple above in favor of a way greener scenery like such:

So without further ado, let's dig into how you can get there too.

Umbraco's attributes

We rely on Umbraco's Tests:Database config and the [UmbracoTest] attribute to provide databases (or not). The Database option works almost as expected, but the four non-none options end up doing the same: they prepare one db for the lifetime of the setup fixture.

[ExtendableSetUpFixture]

The first attribute you have to know is [ExtendableSetUpFixture]. It's sole purpose is to enable the rest of them. Since it's inherited from [SetUpFixture], it tells NUnit we won't add any [SetUp], [TearDown] or [Test] methods in the marked class. But this is the attribute we'll add to any UmbracoIntegrationTest or UmbracoTestServerTestBase, and those have a bunch of each. That's why we have...

[MakeOneTimeLifecycle]

The first attribute in the package that does something. [MakeOneTimeLifecycle] lets you mark methods in otherwise not accessible base classes like UmbracoTestBase to become [OneTimeSetUp] methods rather than [SetUp] methods, and [TearDown] methods becomes [OneTimeTearDown].
Here's an example of what we'd feed it for an UmbracoIntegrationTest inheritor:

[UmbracoTest(Database=SchemaPerFixture, Boot=true)]
[ExtendableSetUpFixture]
[MakeOneTimeLifecycle(
    setUpNames: [nameof(UmbracoIntegrationTest.Setup), nameof(UmbracoIntegrationTest.SetUp_Logging)],
    tearDownNames: [
        nameof(UmbracoIntegrationTest.TearDown), nameof(UmbracoIntegrationTest.TearDownAsync), 
        nameof(UmbracoIntegrationTest.FixtureTearDown), nameof(UmbracoIntegrationTest.TearDown_Logging)
    ]
)]
public class MyLongLivedUmbracoSetUp : UmbracoIntegrationTest
{
}

I found it a bother to write that long attribute all the time, so there's a derived one called:

[OneTimeUmbracoSetUp]

It makes it slightly less messy by letting us write as follows:

[UmbracoTest(Database=SchemaPerFixture, Boot=true)]
[ExtendableSetUpFixture]
[OneTimeUmbracoSetUp]
public class MyLongLivedUmbracoSetUp : UmbracoIntegrationTest
{
}

Note however that the current version doesn't come with a 100% compatible one for UmbracoTestServerTestBase or ManagementApiTest<>, but it's easy to make one yourself, and they're likely suddenly in the package.

Now if you're into hacking around the environment and hidden, protected members lurking around in memory, we're quite alike. But when doing professional work that's often not what we're paid for. So even though the above code will start up a perfectly fine Umbraco instance with a SQLite database it doesn't do much good. We need to get at the IServiceProvider somehow...

[InjectionProvider(string)] and [ServiceProvider]

There is a limit to how many attributes we'll stick on our setup fixtures, I promise. I complained about intermediate base classes earlier, but a few for attribute consolidation is cool enough. OK, these two are a basic re-usable one and a "defaulted" one. The [InjectionProvider(string)] attribute stores a reference to a property on the setup fixture that exposes an IServiceProvider instance. Umbraco's base classes exposea property called Services, and [ServiceProvider] is just a derived [InjectionProvider(nameof(Services))]. To be specific, the service provider reference goes into the test context property bag as a factory method.
By adding one to our growing tower we're ready to meet our first actual test fixture enjoying the power of:

[Inject(string)]

To enjoy the benefits of our stored service provider reference, we must expose an instance method on our "scoped" test fixture that accepts services. We could've used constructor injection, but that's already "in use" by NUnit [TestFixture(args)] functionality. Once you start composing tests like this package allows, you can get much more value from things like that. So a void method will have to do. A fresh "standalone" and "scoped" test fixture will look like this:

using Same.Namespace.As.SetupFixture;

[Inject(nameof(Inject))]
public class LookMaImFreeAsABird
{
    IDataTypeService dataTypeService = null!;

    public void Inject(IDataTypeService dataTypeService)
    {
        this.dataTypeService = dataTypeService;
    }

    [Test]
    public void FiddleWithDataTypeA()
    {
        // ...
    }

    [Test]
    public void CreateDataTypeB()
    {
        // ...
    }
}

Notice the beauty of no forced ctors, no base class and no overrides in that class! Not to mention, you can have several of those!

Interlude: Transactions

With the above setup the individual fixtures are free to create ICoreScope instances from Umbraco and commit or dispose them as you wish. Just writing three sentences about it here doesn't really give the method justice. Suffice to say, just give it a go!
However it won't work when we use UmbracoTestServerTestBase. There's no way to spread a core scope across threads, and there's not even a way to spread gool old .NET transaction scopes across. I guess you could go full old school and bring DCOM into the picture, but after a lot of failed attempts I finally stumbled over an obvious solution.

Snapshots

The final itch has taken me the longest, and even longer to stuff into an attribute rather than yet another base class. I must admit it took a desperate (but accurate) final plea with ChatGPT 5.1 to see the obvious solution just lying there to implement. All database engines, or at least the two I've implemented, support some sort of fast backup. VACUUM INTO in SQLite and CREATE/RESTORE DATABASE AS SNAPSHOT in SQL Server.

I had two intermediate base classes for a few weeks, but this last weekend I ran over the goal line:

`[ReusableDatabase(type, string)]`

If you configure Tests:Database:DatabaseType in your appSettings.Tests.Local.json and set any of the non-none values in the [UmbracoTest] database parameter, you can also add [ReusableDatabase(typeof(SeedClass), nameof(SeedClass.Configure))] to get a new type of ITestDatabase.

As of writing it requires a method to be implemented in the setup fixture, or on some supporting type. Its mission is to configure whether the database needs a fresh seed and how to seed the initial data for all the tests. Only if we say so, the database is installed and re-seeded. For all other scopes it's just restored from that initial snapshot.

The seeding can be done in any way you please. My favorite is importing things using uSync, and that might just become another blog post. For simplicity let's say we're testing variants of property editors based on a datatype we want all tests to start with:

[UmbracoTest(
    Database = UmbracoTestOptions.Database.NewSchemaPerTest,
    Boot = true,
    Logger = UmbracoTestOptions.Logger.Console
)]
[ExtendableSetUpFixture]
[OneTimeUmbracoSetUp]
[ServiceProvider]
[ReusableDatabase(nameof(ConfigureSeeding))]
public class ReusedDbAttributeSetUp : UmbracoIntegrationTest
{
    public static void ConfigureSeeding(ReusableTestDatabaseOptions options)
    {
        options.NeedsNewSeed = _ => Task.FromResult(true);
        options.SeedData = async (services) =>
        {
            await TestContext.Progress.WriteLineAsync("Creating datatype");
            await services.GetRequiredService<IDataTypeService>().CreateAsync(
                new DataType
                (
                    new TextboxPropertyEditor
                    (
                        services.GetRequiredService<IDataValueEditorFactory>(),
                        services.GetRequiredService<IIOHelper>()
                    ),
                    services.GetRequiredService<IConfigurationEditorJsonSerializer>()
                )
                {
                    Name = "A seeded textbox"
                },
                Umbraco.Cms.Core.Constants.Security.SuperUserKey
            );
        };
    }
}

The method has to be static void. If it's on the setup fixture you can omit the type from the attribute parameters.
Now all tests within this "scope" will have access to the seeded textbox. Such seeding code might quickly grow out of hand though, and that's why I prefer just importing the content schema from the web project in the same repo as my tests.

Which ones to choose

As you've hopefully realized by now you can introduce really slim intermediate base classes that set up the initial environment for a bunch of use-cases and scenarios. Leaving your actual test fixtures free to be composed just as you wish, and with all the features of NUnit at your disposal.

I'm sure you can see that the last setup fixture example above makes for a nice base class to avoid repeating that tower of attributes. The repository has a few examples using a few or all of the attributes.

The final trick I haven't disclosed above is how to do a "mid-fixture" rollback. The reusable database implementations have a "RestoreSnapshot" method, so in a [TearDown] you can go:

await serviceProvider.GetRequiredService<IReusableDatabase>().RestoreSnapshot();

That makes it so that whatever test comes next it's unaffected by the changes you've made. This is of course what happens during [OneTimeSetUp] for any setup fixture using [ReusableDatabase].

If you want to try this out, I recommend going with [ReusableDatabase] (and uSync) for everything that use more than 10ish artifacts like data and content types, not to mention content. Whenever you want to run changes through the Management API, or definitely if you want to test how all your sites' elements look in the Delivery API. It's a no-brainer when you go full integration with UmbracoTestServerTestBase and more than one HTTP call.

If all your tests have all they need in a fresh Umbraco database, but they all mutate it so you need cleanup, it'll be blazing fast if you can use ICoreScope with autocommit off. As long as you don't need to test via HTTP endpoints, this is a better option than restoring the snapshot. Using a snapshot restore between fixtures however is still a nice option to keep around, so I still opt for [ReusableDatabase].

Want more?

I'm definitely going to be in "only fix what breaks for me" mode for a little while, as this was just gonna be a hacktoberfest weekend project. Turned out to take too much of my spare time for one and a half month instead.

But I honestly believe this'll save some trees if applied well to CI pipelines running all day long.
And I've gone from 90 sec to 26 sec to execute a full test suite, a lot of which would run for any filter.

The package is currently listed as a beta (pre-release) on nuget and if it doesn't crash much I might just promote it to full visibility. It's a bit furry on the edges and has a bit of legacy to it (already), but if you stick the namespaces in the project file and leave the stray base classes alone I think you'll be good.

All this is to say I'd love for conversation about what it solves and if it could do it better. I'd love even more to throw out a bit of the code because Umbraco suddenly fixed the core two issues. Let me hear from you if you try it out. Feel free to clone the code and mess about, although I reserve the right to refactor the mess myself that beautiful day I get to keep going with this.

Looking forward to hearing how (and if) you like it. Hope you have a go!

Links

Migrating Umbraco Forms from 7 to modern

Wed, 28 Feb 2024 11:58:06 Z

No migration, no cry

There is no uSync Migrations extension for moving forms from 7 to modern. There isn't even a uSync Forms for V7. However the serialization format for forms on disk didn't change (much?) from 7 to 8, so we can do a trick. (Thanks to Kevin for the tip)
We can do 7 to 8, then 8 to modern.
This applies to files. I have not tried with the forms in database method, but that should be possible to do with database migrations from 7 to 8.

7 to 8

Create an empty V8 site and install the following nuget packages:

UmbracoForms
uSync.Forms

To "migrate" your forms from 7 to 8 you just copy the files over. 😁
Your source files should be in /App_Data/UmbracoForms/Data.
The target should be the same in a V8 site.

When your files are copied you're ready to go into the backoffice.
Go to Settings \ uSync and click Export.

You should now have uSync files for the forms under /uSync/v8/Forms.

8 to modern

Install uSync.Forms in your modern site.
Copy your uSync forms files from the V8 site into /uSync/v9/Forms.

The uSync files will have prevalues in a parsedPreValues field instead of preValues.
uSync Forms import in modern does not like this.
So I made a small powershell script that does the necessary "migration":

param(
    $path
)

$files = Get-ChildItem -Path $path -File

$files | % {
    $fileInfo = $_
    $doc = [xml](Get-Content $fileInfo.FullName)
    $pageNode = $doc.DocumentElement.SelectSingleNode("Pages")
    $origCData = $pageNode.FirstChild
    $pages = [array]($origCData.InnerText | ConvertFrom-Json)

    $results = $pages | % {
        $page = $_
        $page.fieldSets | % {
            $fieldSet = $_
            $fieldSet.containers | % {
                $container = $_
                $container.fields | % {
                    $field = $_
                    if ($field.parsedPrevalues.Length -gt 0) {
                        $field.preValues = $field.parsedPrevalues
                    }
                    $field.psobject.Properties.Remove("parsedPreValues")
                }
            }
        }
    }

    $cdata = $doc.CreateCDataSection((ConvertTo-Json -depth 99 -inputobject $pages))
    $replaced = $pageNode.ReplaceChild($cdata, $origCData)

    $doc.Save($fileInfo.FullName)
}

I called the script fix-usync-forms.ps1 and we can call it as such:

./fix-usync-forms.ps1 [path-to-site]/uSync/v9/Forms

That's it!

We can now go into the backoffice in our modern site.
Go to Settings \ uSync and click "Import" under Forms.

Success

Now all that's left is porting your potential code and views.

Happy migrating! 🙃

Unit Testing the IIS URL Rewrite Module

Mon, 19 Sep 2022 13:09:15 Z

Overview

I can't count on two hands the amount of times I've messed up some IIS redirect rule on our sites. "We need all these 50 old top traffic drivers from the old site, and of course we want five domains per country in case someone mistypes it and Google don't show us as first hit.
Oh, and by the way, everybody should be able to use these three slugs for our new campaigs."

Bloody marketeers!

Wouldn't it be nice if we could write some automated tests that verifies that we've configured the UrlRewriteModule correctly? I've been half-heartedly looking for a way to do this with the proprietary .NET Framework IIS Module, but recently realized while researching it that it's a public middleware in .NET Core.
This means we can start to write unit tests against it, and verify that stuff we want to use with our old .NET Framework sites will work even if we test for - and redirect to domains.

Test dependencies

Since I'm testing the config of a .NET Framework app, I just add a separate .NET Core 6 NUnit test project. Its sole purpose is verifying these redirects.

All the dependencies are nuget packages, but I just went and used some fixed paths to the SDK for now. Here are the test project dependencies:

<ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.1.0" />
    <PackageReference Include="Moq" Version="4.18.2" />
    <PackageReference Include="NUnit" Version="3.13.3" />
    <PackageReference Include="NUnit3TestAdapter" Version="4.2.1" />
    <PackageReference Include="NUnit.Analyzers" Version="3.3.0" />
    <PackageReference Include="Verify.NUnit" Version="17.10.2" />
</ItemGroup>

<ItemGroup>
    <Reference Include="Microsoft.AspNetCore.Http">
        <HintPath>C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\6.0.9\Microsoft.AspNetCore.Http.dll</HintPath>
    </Reference>
    <Reference Include="Microsoft.AspNetCore.Http.Abstractions">
        <HintPath>C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\6.0.9\Microsoft.AspNetCore.Http.Abstractions.dll</HintPath>
    </Reference>
    <Reference Include="Microsoft.AspNetCore.Rewrite">
        <HintPath>C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\6.0.9\Microsoft.AspNetCore.Rewrite.dll</HintPath>
    </Reference>
    <Reference Include="Microsoft.AspNetCore.Http.Features">
        <HintPath>C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\6.0.9\Microsoft.AspNetCore.Http.Features.dll</HintPath>
    </Reference>
    <Reference Include="Microsoft.AspNetCore.Hosting.Abstractions">
        <HintPath>C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\6.0.9\Microsoft.AspNetCore.Hosting.Abstractions.dll</HintPath>
    </Reference>
    <Reference Include="Microsoft.Extensions.Features">
        <HintPath>C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\6.0.9\Microsoft.Extensions.Features.dll</HintPath>
    </Reference>
    <Reference Include="Microsoft.Extensions.Hosting.Abstractions">
        <HintPath>C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\6.0.9\Microsoft.Extensions.Hosting.Abstractions.dll</HintPath>
    </Reference>
    <Reference Include="Microsoft.Extensions.Logging.Abstractions">
        <HintPath>C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\6.0.9\Microsoft.Extensions.Logging.Abstractions.dll</HintPath>
    </Reference>
    <Reference Include="Microsoft.Extensions.FileProviders.Abstractions">
        <HintPath>C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\6.0.9\Microsoft.Extensions.FileProviders.Abstractions.dll</HintPath>
    </Reference>
    <Reference Include="Microsoft.Extensions.Options">
        <HintPath>C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\6.0.9\Microsoft.Extensions.Options.dll</HintPath>
    </Reference>
</ItemGroup>

Now that we have them, we can start setting up a totally mocked HttpContext and look at what the IIS UrlRewritingModule middleware does.

The middleware

In order to use the IIS UrlRewriteModule in ASP.NET Core we do app.UseRewriter(RewriteOptions) and on the RewriteOptions we do .AddIISUrlRewrite(FileProvider, "web.config"). All these two things do is camouflaging a middleware and parsing of the config.
What we need in our test is this:

// omitted quite a few web hosting mocks
var reader = // some way to read our config as a web config file
var options = new RewriteOptions().AddIISUrlRewrite(reader);
var middleware = new RewriteMiddleware(_ => Task.CompletedTask, Mock.Of<IWebHostEnvironment>(), loggerFactory, new OptionsWrapper<RewriteOptions>(options))
middleware.Invoke(httpContext);
Verify(state);

All necessary code is at the bottom of this post.

Reading the configuration

We usually put our rewrite rules in a separate file in the web project. It's linked from the web.config file using the configSource attribute as such:

<system.webServer>
    <rewrite>
        <rules configSource="config\RewriteRules.config" />
    </rewrite>
</system.webServer>

To be frank it's actually done on publish using a transform file, so we don't have it configured when working locally.
The rules are then managed in a file looking like this:

<?xml version="1.0" encoding="utf-8" ?>
<rules>
    <rule enabled="true" name="test">
        <match url="(.*)" />
        <conditions logicalGrouping="MatchAll">
            <add input="{HTTP_URL}" pattern=".*abc.*" matchType="Pattern"  />
        </conditions>
        <action type="Redirect" redirectType="Found" url="/tada" />
    </rule>
</rules>

However the AddIISUrlRewrite extension for the RewriteOptions require a stream of a full web.config file. I've just hacked together a small factory method that wraps our config in a slim web.config envelope:

var path = Path.Join(AppDomain.CurrentDomain.BaseDirectory, @"..\..\..\..\Customer.Web\config\rewriterules.config");
var contents = File.ReadAllText(path)
    .Replace("<?xml version=\"1.0\" encoding=\"utf-8\" ?>", "");
var fullContents = "<?xml version=\"1.0\" encoding=\"utf-8\" ?><configuration><system.webServer><rewrite>" + 
                    contents +
                   "</rewrite></system.webServer></configuration>";
var reader = new StringReader(fullContents);

It can now be passed to AddIISUrlRewrite and we're good to go.

A mock HttpContext

The UrlRewriteModule reads from the HttpRequest instance and possibly writes to the HttpResponse instance. We need to mock both these. However the stuff we want to vary is all he URL data, so we pass that to a (fairly large) factory method:

private static HttpContext CreateHttpContext(Uri uri)
{
    var ctx = Mock.Of<HttpContext>();

    var resp = Mock.Of<HttpResponse>();
    var headers = new HeaderDictionary();
    Mock.Get(resp).Setup(x => x.Headers).Returns(headers);
    Mock.Get(ctx).Setup(x => x.Response).Returns(resp);

    var req = Mock.Of<HttpRequest>();
    Mock.Get(ctx).Setup(x => x.Request).Returns(req);
    Mock.Get(req).Setup(x => x.Path).Returns(new PathString(uri.AbsolutePath));
    Mock.Get(req).Setup(x => x.Scheme).Returns(uri.Scheme);
    Mock.Get(req).Setup(x => x.Host).Returns(new HostString(uri.Host, uri.Port));
    Mock.Get(req).Setup(x => x.PathBase).Returns(new PathString("/"));
    Mock.Get(req).Setup(x => x.QueryString).Returns(new QueryString(uri.Query));

    var variableFeature = Mock.Of<IServerVariablesFeature>();
    var features = new FeatureCollection();
    features.Set(variableFeature);
    Mock.Get(ctx).Setup(x => x.Features).Returns(features);

    Mock.Get(variableFeature).Setup(x => x["HTTP_HOST"]).Returns(uri.Host);
    Mock.Get(variableFeature).Setup(x => x["HTTP_URL"]).Returns(uri.AbsolutePath);
    Mock.Get(variableFeature).Setup(x => x["HTTPS"]).Returns(uri.Scheme == "https" ? "on" : "off");
    return ctx;
}

What to verify?

I was initially trying to verify the HttpResponse. We can do that and test the StatusCode and headers etc. However, I was Console.WriteLineing all the logging and it turns out the UrlRewrite middleware logs perfectly nice descriptions of what happens. It also (usually) stops at the rule that handles the URL, so if we take the last two outputs, we're quite good to go:

Request matched current UrlRewriteRule 'test'.
Location header '//tada' with status code '302'.

Request did not match current rule 'test'.
Current url is http://localhost:80/

If I could have my will, I'd like something like this, and I can have it. :)

http://localhost/abc => Request matched current UrlRewriteRule 'test'. Location header '//tada' with status code '302'.
http://localhost/ => Request did not match current rule 'test'. Current url is http://localhost:80/

So what loggerFactory sets up is an instance that keeps a local message log, and of course write to the console:

public class RedirectLogger : ILogger
{
    public List<string> Messages { get; } = new List<string>();

    public void Log<TState>(LogLevel logLevel, EventId eventId, TState state, Exception? exception, Func<TState, Exception?, string> formatter)
    {
        var output = formatter(state, exception);
        output = output.Replace("Request is done processing. ", "");
        output = output.Replace("Request is continuing in applying rules. ", "");
        Console.WriteLine(output);
        Messages.Add(output);
    }

    public bool IsEnabled(LogLevel logLevel)
    {
        return true;
    }

    public IDisposable BeginScope<TState>(TState state)
    {
        throw new NotImplementedException();
    }

    public override string ToString()
    {
        return String.Join(" ", Messages);
    }

    public string Last(int count = 2)
    {
        return String.Join(" ", Messages.TakeLast(count));
    }
}

I keep that instance around for the test to verify what was written to it.

Trying it together

The last piece here is Verify which we can use for larger "assertEquals" blocks.

I'd like one big report of different URLs I expect hit the server, and then the result for each url. So I set up a bunch of testcases like so:

public static Uri[] TestCases() => new[]
{
    new Uri("http://localhost/abc"),
    new Uri("https://localhost/abc"),
    new Uri("http://localhost/tadabcada"),
    new Uri("http://localhost/"),
    new Uri("http://localhost/tada")
};

Now we can loop over those and verify a report in our test:

[Test]
public async Task Handles_All_Rules()
{
    List<string> results = new List<string>();
    foreach(var uri in TestCases())
    {
        var ctx = CreateHttpContext(uri);

        redirectLogger.Messages.Clear();
        await middleware.Invoke(ctx);

        results.Add(uri + " => " + redirectLogger);
    }

    await Verify(String.Join(Environment.NewLine, results));
}

Our output becomes:

http://localhost/abc => Request matched current UrlRewriteRule 'test'. Location header '//tada' with status code '302'.
https://localhost/abc => Request matched current UrlRewriteRule 'test'. Location header '//tada' with status code '302'.
http://localhost/tadabcada => Request matched current UrlRewriteRule 'test'. Location header '//tada' with status code '302'.
http://localhost/ => Request did not match current rule 'test'. Current url is http://localhost:80/
http://localhost/tada => Request did not match current rule 'test'. Current url is http://localhost:80/tada

Fairly easy to read, and now we'll blow up if ever we break our rules.

I think the readability can be tweaked for even better readability and intuition, but for now I'm super happy I can test it. There are tons of other cases I haven't covered of course, but this is a very good starting place.

One quirk I've noticed is that the location header always gets a leading slash, but i think that's due to running in a test.

Hope you like it.
I'd love comments about usage or extensions. :)

All the code

Here's all the code reading the config from a resource file instead:

using Microsoft.AspNetCore.Rewrite;
using Moq;
using DiffEngine;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Http.Features;
using Microsoft.Extensions.FileProviders;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Options;
using Newtonsoft.Json.Linq;
using NUnit.Framework;

namespace UrlRewrite.Tests
{
    public class UrlRewriting
    {
        public static Uri[] TestCases() => new[]
        {
            new Uri("http://localhost/abc"),
            new Uri("https://localhost/abc"),
            new Uri("http://localhost/tadabcada"),
            new Uri("http://localhost/"),
            new Uri("http://localhost/tada")
        };

        [Test]
        public async Task Handles_All_Rules()
        {
            List<string> results = new List<string>();
            foreach(var uri in TestCases())
            {
                var ctx = CreateHttpContext(uri);

                redirectLogger.Messages.Clear();
                await middleware.Invoke(ctx);

                results.Add(uri + " => " + redirectLogger);
            }

            await Verify(String.Join(Environment.NewLine, results));
        }

        private RewriteMiddleware middleware = null!;
        private RedirectLogger redirectLogger = null!;

        [SetUp]
        public void Setup()
        {
            DiffTools.UseOrder(DiffTool.VisualStudio, DiffTool.Rider, DiffTool.VisualStudioCode);

            var options = CreateOptions(GetType().Assembly.GetManifestResourceStream("UrlRewrite.Tests.testroutes.xml")!);
            redirectLogger = new RedirectLogger();
            var loggerFactory = CreateLoggerFactory(redirectLogger);
            middleware = CreateMiddleware(loggerFactory, options);
        }

        private static HttpContext CreateHttpContext(Uri uri)
        {
            var ctx = Mock.Of<HttpContext>();

            var resp = Mock.Of<HttpResponse>();
            var headers = new HeaderDictionary();
            Mock.Get(resp).Setup(x => x.Headers).Returns(headers);
            Mock.Get(ctx).Setup(x => x.Response).Returns(resp);

            var req = Mock.Of<HttpRequest>();
            Mock.Get(ctx).Setup(x => x.Request).Returns(req);
            Mock.Get(req).Setup(x => x.Path).Returns(new PathString(uri.AbsolutePath));
            Mock.Get(req).Setup(x => x.Scheme).Returns(uri.Scheme);
            Mock.Get(req).Setup(x => x.Host).Returns(new HostString(uri.Host, uri.Port));
            Mock.Get(req).Setup(x => x.PathBase).Returns(new PathString("/"));
            Mock.Get(req).Setup(x => x.QueryString).Returns(new QueryString(uri.Query));

            var variableFeature = Mock.Of<IServerVariablesFeature>();
            var features = new FeatureCollection();
            features.Set(variableFeature);
            Mock.Get(ctx).Setup(x => x.Features).Returns(features);

            Mock.Get(variableFeature).Setup(x => x["HTTP_HOST"]).Returns(uri.Host);
            Mock.Get(variableFeature).Setup(x => x["HTTP_URL"]).Returns(uri.AbsolutePath);
            Mock.Get(variableFeature).Setup(x => x["HTTPS"]).Returns(uri.Scheme == "https" ? "on" : "off");
            return ctx;
        }

        private RewriteMiddleware CreateMiddleware(ILoggerFactory loggerFactory, RewriteOptions options)
        {
            return new RewriteMiddleware(_ => Task.CompletedTask, Mock.Of<IWebHostEnvironment>(), loggerFactory, new OptionsWrapper<RewriteOptions>(options));
        }

        private static ILoggerFactory CreateLoggerFactory(ILogger logger)
        {
            var loggerFactory = Mock.Of<ILoggerFactory>();
            Mock.Get(loggerFactory).Setup(x => x.CreateLogger(It.IsAny<string>())).Returns(logger);
            return loggerFactory;
        }

        private static RewriteOptions CreateOptions(Stream stream)
        {
            using var reader = new StreamReader(stream);
            var options = new RewriteOptions().AddIISUrlRewrite(reader);
            options.StaticFileProvider = Mock.Of<IFileProvider>();
            return options;
        }
    }

    public class RedirectLogger : ILogger
    {
        public List<string> Messages { get; } = new List<string>();

        public void Log<TState>(LogLevel logLevel, EventId eventId, TState state, Exception? exception, Func<TState, Exception?, string> formatter)
        {
            var output = formatter(state, exception);
            output = output.Replace("Request is done processing. ", "");
            output = output.Replace("Request is continuing in applying rules. ", "");
            Console.WriteLine(output);
            Messages.Add(output);
        }

        public bool IsEnabled(LogLevel logLevel)
        {
            return true;
        }

        public IDisposable BeginScope<TState>(TState state)
        {
            throw new NotImplementedException();
        }

        public override string ToString()
        {
            return String.Join(" ", Messages);
        }
    }
}

Brushing up old APIs with Castle DynamicProxy

Tue, 30 Aug 2022 21:04:43 Z

Old APIs?

Recently I had the pleasure of rebuilding a B2B ecom site for a local butchery. It's never been properly integrated with their ERP, but the new site is. The front-end is built using Umbraco 9 and Vendr and hosted on Azure, while the integration side is an ASPNET Core WebAPI solution running closer to the ERP-system. They are using an ERP system that's been around since the nineties. Of course it's been upgraded and modernized throughout the years, but the core APIs are still the same as they've been since then. The maturity of the software says enough about the architecture. We can't say that it didn't work, wasn't maintainable or not durable.

However, programming styles have changed over the years. Back then and earlier it was perfectly sensible to inform function callers about runtime errors and exceptions using integer return codes. Executable binaries still do, though most just exit with a 0. Usually a 0 means all is well while any non-zero value means something didn't go well.

Another thing with such unmanaged APIs is that we have to go through interop. That means we have to mind releasing absolutely all resources we instantiate.

Hence every managed example for this ancient (forgive me) API goes something like this:

Server server = new Server();

int result = server.LogOn();
if (result != 0) {
    goto Fail;
}

ComponentA component = (ComponentA)server.Components[(int)ComponentTypesEnum.ComponentA];
result = component.SetupData();
if (result != 1) {
    goto Fail;
}

result = component.BindData();
if (result != -1) {
    goto Fail;
}

result = component.DoFirstThing();
if (result != 0) {
    goto Fail;
}

result = component.DoSecoondThing();
if (result != 0) {
    goto Fail;
}

goto Cleanup;

Fail:
component.Rollback();

Cleanup:
Marshal.ReleaseComComponent(component);
Marshal.ReleaseComComponent(server);

Did you notice any duplication in there? The examples sport a comment that will stay in there forever, but I found it amusing to add a goto statement. Most would likely have bundled a bunch of nested ifs? We could maybe throw in each if, and have an outer try...
The awake reader will also notice that the first two ifs for the component's common SetupData and BindData methods test for other values than zero.
Said API is like that, and the reason for this is still a mystery to me. One day I might get to know. Note that both Server and ComponentA are interfaces. They don't follow the .net convention of prefixing an I.

Then finally of course we have to do this fancy static call to release each of the unmanaged instances.

For orders sake, I intentionally wrote the example in C# 1.0 style to drive the nail in.

How should it be?

In the .NET world we're used to things throwing exceptions. Things we have to clean up are all "disposable". Wouldn't it be nice if the code above was as such too? (To save some bytes and indenting we're now doing C# 8.0)

using var server = ComponentFactory.CreateServer();
using var component = server.CreateComponent<IComponentA>();
try
{
    server.LogOn();

    component.Initialize();
    component.DoFirstThing();
    component.DoSecoondThing();
}
catch(CustomAPIException ex)
{
    component.Rollback();
    SomeLogger.LogError(ex);
    throw;
}

I'm feeling confident I don't have to argue the benefit of the latter example. So how do we make the API work like this instead? Hopefully not by wrapping absolutely all the components with hand crafted code. Not generated classes either, if all they contain are the duplicated four lines of code per call.
Enter Castle.DynamicProxy!

Dynamic proxies

If you've ever used ORMs like NHibernate and Entity Framework, mocking libraries like Moq and RhinoMocks, webservice proxies and whatnot, you've probably been using them without even knowing. Dependency Injection Frameworks (Especially Castle Windsor) may also provide fancy mechanisms to decorate without adding more implementations.
Dynamic Proxies are a mechanism to generate code at runtime. If you have a non-sealed class, you can have a derived class built at runtime, and then instantiate that one.

The wonderful thing about them is that they can be used to wrap existing implementations. (not only yors) Take the example of the return code in the ancient API. Wouldn't it be nice if all the methods did that zero-test automagically, and then threw an exception if they failed?

Creating proxies

A first requirement is to take control over the instantiation. In the example we're using the Server instance is the factory for all components. All of those are already proxies, although they are "made" using Microsofts proprietary .NET Framework interop technology and DCOM. (Proprietary Windows distributed transaction handling) That makes the system able to handle transactional business logic on a central server. We have no control over those proxies, though, so we have to wrap and swap out that Components[ComponentTypesEnum type] indexer with something we control. We want to use Castle DynamicProxy to add an IInterceptor that can intercept calls to the component.

In my solution I came up with this extension that just makes it look like we have a generic overload on Server. One could investigate ways of preventing calls to the "old" one if convension is not enough.

Code to create a "component" becomes server.CreateComponent<T>(ComponentTypeEnum type), which seems a bit more "factoryish". We still have the enum in there, but I'll leave my suggested fix for later. (Writing the blogpost, I cringe at the missing opportunity to remove it...)

To be able to add an interceptor to all calls to a type we use a ProxyGenerator instance, and call it's CreateInterfaceProxyWithTarget method. To which we pass the component itself, and one or more IInterceptor implementations.

public static class ComponentFactory
{
    private static readonly ProxyGenerator Generator = new ProxyGenerator();

    public static T Create<T>(this Server server, ComponentTypeEnum componentType)
    {
        var component = server.Components[(int)componentType];
        return Decorate<T>(component);
    }

    public static T Decorate<T>(object component)
    {
        var proxy = (T)Generator.CreateInterfaceProxyWithTarget(
            component,
            new ErrorWhenResultNotZeroInterceptor()
        );
        return proxy;
    }

    // ...
}

As you can see we still use the Components[index] "factory" indexer to create the requested component, but we use Castle DynamicProxy to add our ErrorWhenResultNotZeroInterceptor.

The decorating error handler

An IInterceptor implementation requires one single method to be implemented: Intercept(IInvocation invocation). It will be called for any extendable or implementable member on the decorated instance. In order for the decorated instance to be called at all, we must call invocation.Proceed(). Otherwise, we've basically create a "no-op" override.

The IInvocation instance contains information about the member intercepted, the return value after invocation etc. We're certainly interested in the return value.

But remember we have those two rogue methods that don't return zero for success? That's where the reflection info comes in handy. Here's the entire code for the "convert non-zero to exception" mechanism:

public class ErrorWhenResultNotZeroInterceptor : IInterceptor
{
    private static readonly Dictionary<string, int> okValues = new Dictionary<string, int>
    {
        { "SetupData", 1 },
        { "BindData", -1 }
    };

    public void Intercept(IInvocation invocation)
    {
        invocation.Proceed();
        var result = (int)invocation.ReturnValue;
        var methodName = invocation.Method.Name;
        var expectedSuccess = okValues.ContainsKey(methodName) ? okValues[methodName] : 0;
        if (result != expectedSuccess)
        {
            throw new CustomAPIException(result, methodName);
        }
    }
}

Et voilá! Now any time we call a component's methods and it doesn't return a zero, an exception is thrown instead.

We've handled the biggest annoyance, and can now write code as such:

try
{
    server.LogOn();

    component.SetupData();
    component.BindData();
    component.DoFirstThing();
    component.DoSecoondThing();
}
catch(CustomAPIException ex)
{
    component.Rollback();
    throw;
}

As you might notice, my ideal code had component.Initialize() instead of the Setup/Bind pair. I leave it as an excercise for the reader to create that extension.

Disposability

To intercept calls to IDisposable.Dispose and replace them with calls to Marshal.ReleaseComObject requires a fairly simple IInterceptor implementation:

public class DisposableInterceptor : IInterceptor
{
    private const int MaxReleases = 100;
    private readonly object real;
    private readonly Guid id = Guid.NewGuid();

    public DisposableInterceptor(object real)
    {
        this.real = real;
    }

    public void Intercept(IInvocation invocation)
    {
        if (invocation.Method.Name != "Dispose") return;

        var i = 0;
        var result = -1;
        while (result != 0 && i++ < MaxReleases)
        {
            result = Marshal.ReleaseComObject(real);
        }
    }
}

But the whole endeavour is about to get quite a bit more painful. There might be easier ways, but I actually ended up generating some code pre-compile time for this trick. However, there's only one line of code per component in the API. (Two, really, but hey...)

Thing is that neither the core Component interface, nor the derived IndividualComponent interfaces implement the IDisposable interface. So we have to create our own IDisposableIndividualComponent interfaces that inherit both the individual one and IDisposable.

For me the most natural step was to create an explicitly ran unit test I can run at will. It's really a one off, but the tests were great for getting there:

[TestFixture]
[Explicit("Run this to generate pastable code with disposable versions of API components")]
public class CodeGeneration
{
    [Test]
    public void GenerateDisposableCustomComponents()
    {
        var types = GetComponentTypes();
        foreach (var type in types)
        {
            Console.WriteLine($"public interface I{type.Name} : {type.Name}, IDisposable {{}}");
        }
    }

    [Test]
    public void GenerateTypeMapForFactory()
    {
        var types = GetComponentTypes();
        foreach (var type in types)
        {
            Console.WriteLine($"{{ typeof(I{type.Name}), typeof({type.Name}) }},");
        }
    }

    private static IOrderedEnumerable<Type> GetComponentTypes()
    {
        var baseType = typeof(IComponent);
        var allTypes = baseType.Assembly.GetModules().SelectMany(m => ModuleTypes(m));
        var types = allTypes
            .Where(t => t.IsInterface && baseType.IsAssignableFrom(t) && !t.Name.StartsWith("I"))
            .OrderBy(t => t.Name);
        return types;
    }

    private static Type[] ModuleTypes(Module m)
    {
        try
        {
            return m.GetTypes();
        }
        catch (ReflectionTypeLoadException e)
        {
            return e.Types.Where(t => t != null).ToArray();
        }
    }
}

The first test generates one line per component as follows. We're somewhat in luck as well. The API in question doesn't follow the .net convension of prefixing interface names with I, so we don't have to invent any ingenious pre- or suffix to our interface names.

public interface IServer : Server, IDisposable { }
public interface IComponentB : ComponentB, IDisposable { }
public interface IComponentC : ComponentC, IDisposable { }
// ...

(Yes, the API sports better names that ComponentA, B etc. I'm just obfuscating it.)

The second test generates a map for the factory to find the right interface to decorate the actual one with:

private static readonly Dictionary<Type, Type> TypeMap = new()
{
    { typeof(IServer), typeof(Server) },
    { typeof(IComponentB), typeof(ComponentB) },
    { typeof(IComponentC), typeof(ComponentC) },
    // ...
}

Likely both groups of "one-liners" per component could've been generated at runtime as well, but I'm sure this'll save some CPU cycles.

This is the place to suggest that the enum parameter could also get its own map and we could ditch that last factory argument.

The factory can now be updated to create instances of our disposable interfaces instead of the original interfaces. Castle DynamicProxy's ProxyGenerator has another factory method called CreateInterfaceProxyWithTargetInterface. It takes a bunch more arguments than the one we've used till now. It needs the new disposable type, the original implementation type, the actual component and the decorators.

Additionally, we need to discriminate between calls to the Dispose method, calls to methods returning int and other methods when we intercept. We don't want either interceptor to run on incompatible methods.

The factory method also accepts an options instance where we can pass something called an IInterceptorSelector.

Here's the complete factory code looking up the types and sewing it all together:

public static class ComponentFactory
{
    private static readonly ProxyGenerator Generator = new ProxyGenerator();

    private static readonly ProxyGenerationOptions Options = new ProxyGenerationOptions
    {
        Selector = new InterceptorSelector()
    };

    public static T Create<T>(this Server server, ComponentTypeEnum componentType)
    {
        var component = server.Components[(int)componentType];
        return DecorateWithDisposable<T>(component);
    }

    public static T DecorateWithDisposable<T>(object component)
    {
        var targetType = TypeMap.ContainsKey(typeof(T)) ? TypeMap[typeof(T)] : typeof(T);
        var implemented = TypeMap.ContainsKey(typeof(T))
            ? new[] { typeof(IDisposable), typeof(T) }
            : new[] { typeof(IDisposable) };
        var proxy = (T)Generator.CreateInterfaceProxyWithTargetInterface(
            targetType,
            implemented,
            component,
            Options,
            new DisposableInterceptor(component),
            new ErrorWhenResultNotZeroInterceptor()
        );
        return proxy;
    }

    public static Server CreateServer()
    {
        return DecorateWithDisposable<Server>(new ServerClass());
    }

    private static readonly Dictionary<Type, Type> TypeMap = new() {
        // ...
    }
}

The interceptor selector then does some "simple" filtering (and a few nice modern C# pattern matches) to select the relevant interceptor:

public class InterceptorSelector : IInterceptorSelector
{
    public IInterceptor[] SelectInterceptors(Type type, MethodInfo method, IInterceptor[] interceptors)
    {
        if (method.ReturnType != typeof(int))
            interceptors = interceptors.Where(x => x is not ErrorWhenResultNotZeroInterceptor).ToArray();

        if (method.DeclaringType == typeof(IDisposable))
            return interceptors;

        return interceptors.Where(x => x is not DisposableInterceptor).ToArray();
    }
}

And that's it! We can now write code like such:

using var server = ComponentFactory.CreateServer();
using var component = server.CreateComponent<IComponentA>();
try
{
    server.LogOn();

    component.Initialize();
    component.DoFirstThing();
    component.DoSecoondThing();
}
catch(CustomAPIException ex)
{
    component.Rollback();
    SomeLogger.LogError(ex);
    throw;
}

Summary

So we've gone on a deep dive through both "easy" extensions and more complex ones like adding disposability. I really hope it sparked some inspiration.

I'm sure there are tons of ways to utilize this, but make sure to use it as the right tool for the right job, and not for the sake of using it.

For one, the decorator pattern is way easier to apply to large interfaces than generating tons of wrapper code to decorate only a few of the methods on a type. I usually write individual classes for each use case (read command or query), so generic decorators can be as simple as IInterceptor implementations anyway. But for APIs not built like this, Castle DynamicProxy makes it a breeze!

For debugging purposes, turning on and off a console logger that prints each method called and its result is also quite nice. Especially within unit-tests.

Got any other great ideas? Drop them in the comments.

Thanks for reading!

Analyzing W3C logs with Excel and PowerQuery

Wed, 06 Jan 2021 00:34:42 Z

15 Years ago I wrote a .net WinForms tool called "IIS Log Viewer" to parse and visualize W3C log files in a nice color coded grid. Of course it topples over as soon as you analyze a file of some respectable size, so I'm sorry to say I abandoned maintenance of the program. Only today I realize I should have called it "W3C Log Viewer", but here's to hindsight. 🤣🍻

Today I use a different approach with Excel and PowerQuery instead. In this article I'll show how you can anlyze a fair amount of traffic (at least a million requests) from several logfiles possibly spanning your entire retention period. I'm a Microsoft fanboy, so I'll show how to do it with Azure App Services logging to Azure Storage accounts, but you can point to filesystem folders as well.

Setting up W3C logging on an Azure App Service

The nicest way of HTTP logging I know of on Azure is by logging to storage. It'll persist across slots when you swap, and you won't have to download them to analyze them.

You'll find the settings you want under Monitoring\App Service Logs:

Now, you'll production slot will happily rotate n days of logs in your storage account. They'll be stored in a hierarchy by slot name (?), year, month, date and finally hour. Totally horrible to analyze without a tool, but we got just the one! Also too difficult to screenshot, so you'll have to imagine it. 😇

Getting data into Excel

I believe PowerQuery really made it's break into Excel in the 2016 version. We'd had some "Power" tools (pivot?) from 2013, but this version really hit the target! I can't get over the fact I waited until 2020 to get more acquainted with it.

In the old versions, we more or less only had the horrible text import / split column wizard. In newer versions of Excel we've got a super rich "Get & Transform Data" section in the Data ribbon, not to speak of (almost) the full power of PowerQuery behind the scenes.

The "new" Excel data ribbon

I particularly like the "From Web" one, since it'll handle most modern formats such as JSON and XML. (Even CSV)

However, for our purposes, we'll find our source of choice by drilling into the "Get Data" dropdown:

We go on to enter our storage account name:

Then you'll need to find your account key and enter it in order to authorize with Azure:

Mind the security concerns and the data firewall when authenticating sources and sharing connected Excel files.

The next "wizard" we're faced with is a blob storage browser. We'll select the "logs" container, but leave it at that. We want to "load and transform" all the blobs we see on the right hand side.

So the final step is to resist the urge to click "Load", but rather click "Transform Data". This will launch the most powerful data transformation tool I know to date, the aptly named "PowerQuery" GUI.

Getting the contents of all the log files

Excel will immediately pop a new (sadly modal) window with a new Query aptly called "logs". The smiley up there is for sending feedback, but I like to think PowerQuery is just a happy place alltogether.

As you can see there's a bunch of options up top, but we're actually after a slightly more inconspicuous one down in the "Content" column header called "Combine files":

This will pop another dialog asking us about encoding and whether we want to skip things that bugs out. Also we can choose which file to use as our sample for further transformation:

We'll go ahead and use the first one, since the sequence of those don't matter. The're all in the same format. What follows is this:

We're now faced with a fairly more complex set of queries and steps in our "logs" query. The inner workings of those are out of the scope of this post, but I promise there's magic to be had if you'll dive deeper. The .net peeps reading this will also appreciate the familiar form of static method calling in the "formula bar". PowerQuery is a delightful blend of familiar syntaxes. 😇

The more interesting thing however is that (very quickly) the blob file contents are shown in a new column called "Column1". This is our next target.

Transforming the data and preparing for analysis

Before we can make anything meaningful out of the actual log data we have to get rid of some junk, and figure out what fields we've logged. These are the first two lines of the logfile. Alas they've got a bit of junk attached. The first line is just garbage, so we'll employ our first secret weapon. Remove top rows: (it's on the Home ribbon)

You'll be prompted with a dialog asking how many rows to remove. We want to remove the leading hash lines except the "#Fields" one. In my case, this is just the "#Software" row, so I remove 1 row.

The next step is to remove the leading "#Fields: " text of the column header specification. We'll drag out our second weapon of choice, "Replace Values". For this step we need to select "Column1" and move over to the "Transform" ribbon. Here we'll find the "Replace Values" dropdown where we select the values option:

We're faced with (yet) another dialog in which we specify that we want to get rid of the "#Fields: " string: (make sure to include the space)

Splitting columns

We're here! The good old "split column" phase is up!

Back at the home ribbon, we find our old friend "Split Column". For W3C log files we're dealing with space delimited files, so we go with the "by delimiter" option:

Yet another dialog where we specify space as the delimiter:

Now we're definitely getting somewhere:

Notice how we didn't have to specify any other options than how to split the data? No data types, no headers, nothing.

We do need to get those headers as column names, though. We're already on the home ribbon and if you've been looking closely you've likely noticed both "Remove Columns" and "Use First Row as Headers". We'll remove the now useless "Source.Name" column, and then use the first row as our headers:

Then we hit the "Use First Row as Headers" button, et voilá:

The utter sweetness (if you look in the bottom right corner) is that PowerQuery is awesome at guessing data types. Granted you have to nudge it a bit every now and then, but the date, times and numeric data is already properly typed.

Which leads us to the last necessary step for this to work flawlessly. PowerQuery has only sampled 1000 rows from the first file. It's not aware that several more lines starting with a hash is awaiting further down the road. That's gonna mess up it's date conversion for the first column. Here's for our final trick, "Remove errors". It's an option under our old friend "Remove rows" on the home ribbon. Make sure to select the date column before you hit it:

And that should be it! We're ready to hit that captivating "Close & Load" button up in the left corner of the home bar. Go ahead! Hit it!

Now depending on whether you've got less than a mil. lines total in your log files this will succeed or fail. Despair not though, there are ways to get around it. I'll add some tips at the bottom.

If you're lucky enough to escape the Excel row limit trap (unlike some unfortunate brits recently), you'll be faced with a fancy green table after a while. The "Queries & Connections" sidebar will appear and show progress of how many rows that's been loaded. (Including errors if any)
For me it takes a few minutes to load half a mil rows. (Granted I'm on a 1GB internet connection yielding .5 GB to my box. It is a few hundred MB to download.)
Here's how it looks:

So we've got half a million log rows loaded to Excel. I can't be bothered to investigate the 680 errors, but if you click the link you'll get a special query showing those and their causes. (❤)

However this is fairly hard to get some value out of in its present state. We need to pivot. If you've got less than a million you can go to the "Insert" ribbon and click "Pivot table". Make sure you've selected a cell in the log table first. Just accept the default options and skip to the next section.

Pivoting more than a million rows

Incidentally pivoting is also the trick (untested) if you've got more than a million rows. You'll have to right click the "logs" query in the "Queries & Connections" toolbar on the right and select "Load to". You can then change to a "Pivot Table" instead of table and skip loading all the details. I believe there's also options to build cached data models, but that's outside of my skillset and the scope of this post as well. :)

Pivoting W3C logs

Which ever way you opt to pivot the log data you'll end up with a worksheet like this:

I've got two favorite setups for analyzing logs. First of all, I'd like to examine whether a spike is due to a new bot of some sorts. We'll just block it if it's something we're not interested in. It can save an amazing amount of processing you possibly weren't aware you spent.

Though we imported all the log files, for this you'd likely want to look at a specific day. Dragging "date" to "Filters" lets you select a date in B2. (Full screenshot further down)

Next we want to look at agents, so we drag "cs(User-Agent)" to "Rows". (They'll all appear instantly)

Finally we want to see how many hits we've got from each agent and then sort. We can actually drag any field, but let's go with "time" for counting. The final dragging step is to drag "time" into "Values".

We should be left with something like this:

As you can see we still have quite a few agents to try to rid ourselves of, but the ones we see here have too acceptable request rates to bother. The one's we'd be interested in would have thousands in the "Count of time" column. To find them easily we have to sort, and this is were Excel can be a bit quirky. In order to sort the pivot by "Count of time" we have to open the dropdown menu on "Row Labels" and select "More Sort Options...":

What follows is a rather quirky dialog, but we're after "Descending (Z to A) by: Count of time":

We're now left with a table showing that todays winner was (bloody) iPhones!

Discovering facts

If we'd had an excessive agent, likely with "bot" in it's name, the next step would be to add "c-ip" as a secondary row dimension under "cs(User-Agent)". We could then drill down into the excessive agent and likely discover IPs to block or even report.

Today however, this process lead me to replacing "cs(User-Agent)" as my rows field with "cs-uri-stem". Repeating the sorting trick showed me that the customer obviously had had a campaign of some sorts leading to the sudden spike at three o'clock. Luckily our newly upgraded S3 plan managed to take it only dropping to 2 secs response time across 29 Umbraco sites, but I'm about to have a serious talk with this particular customer - leading to a slightly more expensive hosting fee for an individual plan. 😇

Another favourite setup of mine shows which URIs (or other interesting dimensions) have errors, redirects or excessive "access denieds".

Rows
- cs-uri-stem
Columns
- sc-status
Values
- time

Conclusion

Using custom tools for file based logs seems to be bygones. PowerQuery can do most popular serialization formats, and within Excel limits it's awesome combined with pivot tables. If the performance isn't good enough, the same techniques can be used with SQL Server, Analysis Services and Power BI, but I guess W3C log format parsing is unnecessary in those kinds of setups.

I find myself using PowerQuery for more and more these days, so don't be surprised if another PowerQuery post sees the light of day this year. Hope you enjoyed following along and maybe even learned something. 🤓

Stubbing the internet with Postman, HttpClient and HttpMessageHandler

Fri, 05 Jun 2020 10:52:32 Z

Using Postman or Insomnia to test code and integrations

Recently Tim Heuer at Microsoft posted a poll on Twitter asking people using tools like Postman and Insomnia why they "just don't rely on test frameworks".

Folks who use tools like postman/insomnia...why don't you just rely on test frameworks?
— Tim Heuer (@timheuer) May 29, 2020

I wanted to pitch in with the method I use, which is a combination of both.

Whenever I integrate with third parties, I almost always start off with a spike to learn how their APIs work.
Right now for instance, I'm building some integrations with the norwegian business registry.
They have a couple of nice and simple endpoints. Here's a Postman request searching for our company, MarkedsPartner.

I also had to run this code from a public webserver in order to find the right request messages from a second third party, so I threw in some HttpClient usage for the above, while logging incoming requests.

I could then replicate the requests in Postman to continue spiking with my mediating API controller.

As soon as I knew all about the incoming and outgoing messages, I was ready to start stabilizing with tests so I could proceed with refactoring and extending.

Stubbing the entire internet

The .NET HttpClient is fully stubbable, but the seam is fairly well hidden. I'm not convinced enough people know about this.
The HttpClient has a parameterized constructor taking the abstract HttpMessageHandler as its only parameter. By default this is a concrete HttpClientHandler when the parameterless ctor is used. Within HttpMessageHandler there is a protected SendAsync method which is the final method called by all the Get, Put, Post methods etc. It receives a HttpRequestMessage and returns a HttpResponseMessage.

You can use mocking frameworks like Moq to stub protected methods. But I really like to build my own fake HttpMessageHandler implementation for HTTP integration tests. In my experience it's actually (way) less code, and provides both stubbing and mocking mechanisms.

The simplest way to build it is to just return the same message for any call, but with a few extensions it's almost like a small stub internet with static resources. Here's how you could build one that varies its responses by request URI:

public class StubHttpClientHandler : HttpClientHandler
{
    public readonly Dictionary<string, HttpResponseMessage> UriResponses = new Dictionary<string, HttpResponseMessage>();

    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        var url = request.RequestUri.ToString();
        if (UriResponses.ContainsKey(url))
        {
            return await Task.FromResult(UriResponses[url]);
        }

        return await Task.FromResult(new HttpResponseMessage(HttpStatusCode.NotFound));
    }
}

To make sure my production call hits this integration border instead of going off to the internet, I have to abstract away the creation of a HttpClient in my code. Often I set up a Func<HttpClient> factory with a DI container, but in my current case it's enough to add a static property to the SUT (system under test):

public static Func<HttpClient> HttpClientFactory = () => new HttpClient();

In my tests, I then swap out that factory with a function that returns a reference to a HttpClient using my StubHttpClientHandler:

var handler = new StubHttpClientHandler();
HttpClient httpClient = new HttpClient(handler);
BrregLookupController.HttpClientFactory = () => httpClient;

The final thing to do is to register a URI with a corresponding response message:

handler.UriResponses.Add(
    "https://data.brreg.no/enhetsregisteret/api/enheter?navn=markedspartner",
    new HttpResponseMessage(HttpStatusCode.OK)
    {
        Content = new StringContent("{\"status\":\"OK\"}", Encoding.UTF8)
    }
);

Whenever the controller now fires a call to that URL, it'll get a response with the JSON provided in the response message. You could add a content-type header and such for good measure, but it's not really necessary depending on how you handle the result.

Bringing Postman responses into the tests

Of course a slim JSON object with a status message isn't what I'm after here. I'm after the exact response the Brreg APIs would give me. Instead of pasting the entire JSON graph seen in the screenshot above, I like to keep them in files instead.

Those kinds of files are excellent candidates for Embedded Resources in the test project. So I paste the entire graph into a JSON file in a "TestResources" folder and make sure the file's build action is "Embedded Resource":

In order to easily provide that content to my stub I usually employ a simple helper class for resources:

public static class TestData
{
    public static string ReadAsString(string resourceName, string suffix = "json")
    {
        using (var resourceStream = typeof(TestData).Assembly.GetManifestResourceStream(
            $"Full.TestProject.Namespace.TestResources.{resourceName}.{suffix}"))
        {
            if (resourceStream == null)
            {
                throw new InvalidOperationException($"Couldn't find resource '{resourceName}'");
            }
            return new StreamReader(resourceStream, Encoding.UTF8).ReadToEnd();
        }
    }
}

Now we can change the stub response as follows:

handler.UriResponses.Add(
    "https://data.brreg.no/enhetsregisteret/api/enheter?navn=markedspartner",
    new HttpResponseMessage(HttpStatusCode.OK)
    {
        Content = new StringContent(TestData.ReadAsString("NameSearchResult.MarkedsPartner"), Encoding.UTF8)
    }
);

Verifying the integration

As long as the SUT returns something serializable, in this case it's an API controller returning a strongly typed transformed version of the data from Brreg, we can verify the entire graph using ApprovalTests. I've blogged about approvaltests before if you don't know what it is. Here's the entire act / assert part of the test:

var response = await controller.Lookup(new LookupRequest
{
    Name = "MarkedsPartner"
});

Approvals.VerifyJson(JsonConvert.SerializeObject(response, JsonConfigurationAttribute.SerializerSettings));

I want to make sure I serialize exactly as the controller formatter will, so I pass the production serialization settings to ApprovalTests. On a sidenote, Approvals.VerifyJson works best with non-indented JSON, so make sure to use settings that have formatting set to None.

Expanding on the stubbed world wide web

There are a couple of other mechanisms I enjoy to use with the StubHttpClientHandler. First of all, we can use it as a mock to verify that our code sends out one-way messages as well. In order to do that we simply record every request in the SendAsync method:

public class StubHttpClientHandler : HttpClientHandler
{
    public readonly List<HttpRequestMessage> Requests = new List<HttpRequestMessage>();
    public readonly Dictionary<string, HttpResponseMessage> UriResponses = new Dictionary<string, HttpResponseMessage>();

    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        Requests.Add(request);

        // ...
    }
}

We can then assert that URLs and even bodies were sent off by our code:

Assert.That(handler.Requests, Has.One
    .Property("RequestUri")
    .EqualTo(new Uri("https://data.brreg.no/enhetsregisteret/api/enheter?navn=MarkedsPartner"))
);

The second mechanism I enjoy is to provide predicates and response factories in order to simplify setup.
For my current code I haven't refined it very much, so it might look a bit complex, but I'm sure you can follow the code. 😊

public class StubHttpClientHandler : HttpClientHandler
{
    public readonly List<HttpRequestMessage> Requests = new List<HttpRequestMessage>();
    public readonly Dictionary<string, HttpResponseMessage> UriResponses = new Dictionary<string, HttpResponseMessage>();
    public readonly List<(Func<HttpRequestMessage, bool> predicate, Func<HttpRequestMessage, HttpResponseMessage> responseFactory)> PredicateResponses = 
        new List<(Func<HttpRequestMessage, bool> predicate, Func<HttpRequestMessage, HttpResponseMessage> responseFactory)>();

    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        Requests.Add(request);

        // Return any match for full URIs
        var url = request.RequestUri.ToString();
        if (UriResponses.ContainsKey(url))
        {
            return await Task.FromResult(UriResponses[url]);
        }

        // Run all predicates and see if one matches
        var predicateEntry = PredicateResponses.FirstOrDefault(x => x.predicate(request));
        if (predicateEntry.responseFactory != null)
        {
            // Create the response using the provided factory
            return await Task.FromResult(predicateEntry.responseFactory(request));
        }

        return await Task.FromResult(new HttpResponseMessage(HttpStatusCode.NotFound));
    }
}

Now we can set up a list of different responses as a dictionary, and then provide different responses based on the parameter. Here we could also add checks that authorization headers or other request requirements are verified by our production code:

Dictionary<string, Func<string>> searchResults = new Dictionary<string, Func<string>>
{
    { "MarkedsPartner", () => TestData.ReadAsString("NameSearchResult.MarkedsPartner")}
};

handler.PredicateResponses.Add((
    predicate: request => 
        request.RequestUri.ToString().StartsWith("https://data.brreg.no/enhetsregisteret/api/enheter?navn="),
    responseFactory: request =>
        searchResults.ContainsKey(request.RequestUri.ParseQueryString()["navn"])
            ? new HttpResponseMessage(HttpStatusCode.OK)
            {
                Content = new StringContent(searchResults[request.RequestUri.ParseQueryString()["navn"]](), Encoding.UTF8)
            }
            : new HttpResponseMessage(HttpStatusCode.NotFound)
));

We can now hide away the slightly unrefactored and ugly stubbing code, while focusing on the parameter / response pairs in the searchResults dictionary.

A search for "MarkedsPartner" will return the expected response, while a search for "Umbraco" for instance would return a 404 response.

Conclusion

Using Postman or Insomnia is really useful for spiking, and it's invaluable when we need stub data for our tests. By leveraging files and embedded resources, we can easily build strong sets of integration tests, stubbed at the very frontier before the code runs off to the internet.

Making sure your own API controllers behave correctly is a matter of verifying with your production binding and serialization settings. Then you won't have to call your own code via tools such as Postman or Insomnia.

This is all necessary for .NET Framework users. For light .NET Core solutions, it should be fairly simple to spin up an inproc webserver and do the entire HTTP process in a speedy manner. However, the stubbed version of the internet is gold here as well.

Hope you found the code interesting and thanks for reading!

Here's a copy of the complete StubHttpClientHandler described in this post:

public class StubHttpClientHandler : HttpClientHandler
{
    public readonly List<HttpRequestMessage> Requests = new List<HttpRequestMessage>();
    public readonly Dictionary<string, HttpResponseMessage> UriResponses = new Dictionary<string, HttpResponseMessage>();
    public readonly List<(Func<HttpRequestMessage, bool> predicate, Func<HttpRequestMessage, HttpResponseMessage> responseFactory)> PredicateResponses = 
        new List<(Func<HttpRequestMessage, bool> predicate, Func<HttpRequestMessage, HttpResponseMessage> responseFactory)>();

    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        Requests.Add(request);

        var url = request.RequestUri.ToString();
        if (UriResponses.ContainsKey(url))
        {
            return await Task.FromResult(UriResponses[url]);
        }

        var predicateEntry = PredicateResponses.FirstOrDefault(x => x.predicate(request));
        if (predicateEntry.responseFactory != null)
        {
            return await Task.FromResult(predicateEntry.responseFactory(request));
        }

        return await Task.FromResult(new HttpResponseMessage(HttpStatusCode.NotFound));
    }
}

Search and RSS for our Umbraco ContentList

Wed, 06 May 2020 13:30:33 Z

The ContentList package have gotten a few new improvements over the last couple of weeks. Here's a rundown on what's new since the initial release post.

Theme control

Often a theme is customized to work well with just one or a few of the data sources. This is especially relevant with the changes described later in this post. Also, a theme might not use bootstrap, and as such not have the same rigid column count structure. Themes have therefore got a new config file you can choose to add to a theme folder: list.json.

There are two options you can add to the list config file:

Compatible sources

To specify which data sources a theme goes well with, add a compatibleSources array:

{
    "compatibleSources": [
        "ListablesByLuceneDataSource",
        "ListableByNodeDataSource",
        "ListableChildrenDataSource"
    ] 
}

Disable columns setting

The FlexTheme example view for instance does its own flexbox styling with varying amounts of columns. For this theme, the columns setting with "mobile", "tablet" and "desktop" column counts make no sense.

You can now disable the columns setting as such:

{
    "disableColumnsSetting": true
}

Search

The ListableByLuceneDataSource have gotten a small brushup. The query setting have gotten its textbox expanded for better UX, and a new parameter called "Fulltext Querystring Parameter" have been added.

The latter will combine the "query" with a search in all fields for all terms in a phrase extracted from the querystring parameter specified in the setting.

There is a new sample template for search where a search box is included in the theme list view. It posts and controls the configured querystring parameter. You can of course also just make a form in your layout posting to a given page with a content list. Or even a grid editor.

Rss

I didn't want to bundle RSS with the core component, so there's a new package on the block called Our.Umbraco.ContentList.Rss. By installing it, you get another data source aptly called "Rss". It's also currently in beta, so remember to add the -pre option when installing.

It has one parameter for the URL to the RSS-feed, so I gather it doesn't need that much documentation.

By specifying some theme settings as described earlier, it should be fairly simple to control both RSS and search themes combined with whatever other creative lists you come up with.

Hope y'all enjoy and find this stuff useful! Don't be shy, come over to the github repo and post issues if you want to discuss, ask questions or (please do) contribute.

Our.Umbraco.WysiwygGrid 1.0.0 beta released

Thu, 23 Apr 2020 12:09:36 Z

A while ago I blogged about the state of WYSIWYG in the Umbraco grid editor. We're now about to add this script to a second and likely third Umbraco 8 site, so I had to generalize and package up the code.

There's nothing much to hide or earn from here, so I decided to put it up on github and nuget instead of our internal scm and feeds.

Hope to see some more community members fiddling with it, if nothing else that it inspires the block editor team to make the backoffice experience more similar to the frontend look and feel.

A definite change from the previous blogpost is that we favor grid settings over inline styling. By slightly modifying the bootstrap view (we use v4 anyway), we can add multiple classes instead of attributes as is done the original views. As such we can have settings like these:

Those will generate extra classes named padding-lots and theme-inverse.
Those classes are added to rows or cells in both the backoffice and the front-end.
By doing some fancy sass include ninjaing, we can hopefully limit the amount of duplication, while still mimicing the front-end as much as possible in the backoffice.

There are some samples in the github repo if you're unsure how to get started. The SQLCE database is included with a fairly common test username/password. 😇

Without further ado, here's the nuget and github links:

https://github.com/lars-erik/Our.Umbraco.WysiwygGrid
https://www.nuget.org/packages/Our.Umbraco.WysiwygGrid/1.0.0-beta01

Hope you enjoy it, and as usual, hope for a good discussion or feedback from the community!

The state of WYSIWYG grid editing in Umbraco - a prototype

Fri, 03 Apr 2020 13:26:14 Z

The state of the grid

Since the grid was launched at the CG talk "The sky is the limit" back in 2015 (i think), it has been a joy to use for editors, designers and developers alike. Granted, there's been the other feature that could've gotten more love (configuration and settings), but generally it does the job swell.
However, it's still just a white canvas with "settings applied".
Antoine made LePainter back in 2015, but likely didn't get much traction.
I was just told about it today by Callum. Shame on me for not watching the package space enough, how embarrasing. 😳

Anyway...

Why should we care

Recently, I've been in lots of discussions; near battles IMO; about which CMS to sell to our customers.
The feedback is that editors wonder why what they see while editing does not match what they see in the front-end. We do work with another CMS where the backoffice experience has a near 1:1 layout and design with the front-end. As developers, we tend to think structured data is the better solution. Think nested- and stacked content. I tend to agree. But in a sales meeting, those arguments are total losing arguments. A competing agency will bury you when they oversell the fancy editing experience. Even though the not-so-apparent technical features of the competing CMS are totally useless.
And I do agree - the editing experience is what Umbraco likes to sell as well!

What can we do?

The current HQ efforts are working on the "block based" editor. It's been going on for the better part of a year, but the publicly available information is mostly just an RFC with screenshots looking like stacked / nested content, and that's it. The technical aspects seem super, but there's nothing much (but text) about the general editing experience. Also, and I know this is a hot take, editors DO want to see three columns in the editor when it ends up three columns in the front-end.

Hopefully, as mentioned in the RFC, it can act as a stepping stone towards the "Grid 2.0" (which we started work on at the retreat two years ago).

But as far as I'm concerned, this could just as well end up never happening. The effort is not very visible, Project UniCore 🦄 has (rightly) high priority, and in the mean time we're stuck with Grid 1.0, or maybe, hopefully, a rumored commercial package called Bento by the eminent Peter Gregory and his colleagues at KØBEN Digital.

A prototype

So back using Grid 1.0 for projects to be delivered imminently, I've started doing some prototypes for something similar to what LePainter did for early v7 projects.

I asked the community if it was madness or worth pursuing, and the general feedback is that it's both. Hence this blog post to explore it some more, and hopefully gather some more feedback or at least provide feedback to the block editor team. (Hope they receive it. 😁)

Here's a quick little preview of what I've been doing so far:

The issues

Actually getting the styling into the grid is "just" a matter of including a few pagefuls of JavaScript and a limited and scoped CSS file in a package.manifest file for the site. Both classes and styles are applied as expected, and with some due dilligence it doesn't look half bad.

The biggest issue I have is that the cells and controls are styled white, and while styling one have to mind not messing up the GUI text like "Settings applied".

I attempted to lessen the opacity of the cells and controls, and it works to a degree. The minute one adds a background image however, the entire thing starts to crumble. How to keep the WYSIWYG experience while still seeing the GUI? One could fantasize about doing an average color sample of the image and toggling between white and black text, maybe? Could be done in a short hacking sprint...
Could just keep it fairly white like I've done in the prototype. Could keep just the active rows white. This is where I start struggling. 😳

To be frank, the biggest problem lies in the fact that the "Add content" button is in the grid. Other CMSes have drag drop functionality from a menu over to the side. It could possibly still just be white or slightly transparent. The last problem then is all those "settings applied" and empty cells with the other type of "Add content" button.

I can't help but think this is all within grasp, albeit just out of my limited back-ender reach. 😆

The settings dialog issues

The settings dialog is a chapter of itself. It's a mystery to me why we still have a concept of individual "prevalue editors" in Umbraco. Property editors have the same model, and can be sneaked in there by just providing a full path.

However, as experienced when working on our ContentList package, nesting property editors using built-in directives wreaks total havok on the styling. There's some grey background and drop shadows - that I haven't seen being actively used anywhere. It's generally just a mystery, and a huge candidate for backoffice re-work.

Also, for instance the slider property editor does look a bit weird when used as a setting editor. I do hope that those things will get an overhaul and are made more uniform sooner or later.

I'll just leave that hanging, since I know (and appreciate) there are several HQ and community efforts going on to clean things up.

The code

Since I managed to sneak in a few new events in the grid, making it work was a matter of hooking into the "grid.initialized" event and start watching the model. There might be some performance issues with large grids since it's a deep watch, but with todays computers that might be irrational over engineering to think as well.

It adds the configured styles as expected.
For the configuration, it just adds the value of the configuration setting called "class". If there's more it concats the setting key with the setting value, delimited by a dash.

You can scrutinize the JavaScript here, or in this gist.

angular.module("umbraco").run(["eventsService", function(eventsService) {
    function findModelScope(scope) {
        if (!scope) {
            return null;
        }
        if (scope.model) {
            return scope;
        }
        return findModelScope(scope.$parent);
    }

    function isProtectedClass(className) {
        return className === "umb-row-inner" ||
            className === "umb-cell-inner" ||
            className.substr(0, 2) === "ng-" ||
            className.substr(0, 2) === "ui-";
    }

    function addClasses(element, gridItem) {
        function classNameFromConfig(e) {
            if (e === "class") {
                return gridItem.config[e];
            } else {
                return e + "-" + gridItem.config[e];
            }
        }

        var classes = (element.className || "").split(/\s+/);
        var newClasses = classes.filter(isProtectedClass);
        var nameClass = (gridItem.name || "").toLowerCase().replace(" ", "-");
        var configClasses = Object.keys(gridItem.config || {}).map(classNameFromConfig);
        newClasses.push(nameClass);
        newClasses = newClasses.concat(configClasses);
        element.className = newClasses.join(" ");
    }

    function addStyles(element, gridItem) {
        function styleFromKeyPair(e) {
            return e + ":" + gridItem.styles[e];
        }

        var stylesValues = Object.keys(gridItem.styles || {}).map(styleFromKeyPair);
        element.style = stylesValues.join(";");
    }

    eventsService.on("grid.initialized",
        function(evt, data) {
            var modelScope = findModelScope(data.scope);
            var model = modelScope.model;
            var jqEl = data.element;
            var el = data.element.get(0);
            jqEl.addClass("stylized-grid");

            modelScope.$watch(
                "model",
                function () {
                    var areaElements = el.getElementsByClassName("umb-column");
                    if (areaElements.length === 0) {
                        return;
                    }
                    model.value.sections.forEach(function (area, ai) {
                        var rowElements = areaElements[ai].getElementsByClassName("umb-row-inner");
                        area.rows.forEach(function (row, ri) {
                            var rowElement = rowElements[ri];
                            addClasses(rowElement, row);
                            addStyles(rowElement, row);

                            var cellElements = rowElement.getElementsByClassName("umb-cell-inner");
                            row.areas.forEach(function(cell, ci) {
                                addClasses(cellElements[ci], cell);
                                addStyles(cellElements[ci], cell);
                            });
                        });
                    });
                },
                true
            );
        });

}]);

The CSS

To not interfere with any other backoffice styling, the script adds the class "stylized-grid" to the grid container. Here's the (S)CSS I used to make things more transparent:

.umb-grid.stylized-grid { 

    .umb-cell-content {
        background-color: rgba(255, 255, 255, .8);
    }

    .umb-cell-content:hover {
        background-color: rgba(255, 255, 255, 1);
    }

    .umb-cell-content.-has-editors {
        background-color: rgba(255, 255, 255, .8);
    }

    .umb-cell-content.-has-editors:hover {
        background-color: rgba(255, 255, 255, 1);
    }

    .umb-grid-add-more-content {
        background-color: rgba(255, 255, 255, 1);
    }

    .umb-control-bar, .umb-grid-has-config {
        font-family: Lato, Helvetica Neue, Helvetica, Arial, sans-serif !important;
    }

    iframe {
        background-color: transparent;
    }

    @import "../../../Assets/grid";
}

The import at the bottom is the sass that styles our individual components in the front-end, and that should be reflected in the backoffice.

Conclusion

We'll be diving into deep water and testing this out on a real customer. I'm a bit weary, but we need to get the experience.

I do hope I've been able to provide some inspiration, and that WYSIWYG editing in Umbraco might get the renaissance (I believe) it deserves.

Feel free to drop your comments below or ping me on Twitter or Slack!
Also happy to continue the discussion on our or github, but not sure the best way forward, if any.

Our Umbraco Community ContentList 1.0 (beta) released

Wed, 01 Apr 2020 21:57:27 Z

ContentList is a grid editor we've used internally at MarkedsPartner since 2016. It helps editors and designers insert lists of content in the grid without having to worry about queries, paging or building new templates.
I've finally been able to upgrade it to Umbraco 8 and polished it a bit. It's still slightly in beta, but there's nothing special but a bit of CSS polish lacking, so it should be fairly safe to use in production. 👼

There's a whole documentation piece in the readme over on github, so I won't bother with a whole lot of prose in this blogpost, but I recorded a half an hour demo (below) showing all the aspects of implementing its use in an Umbraco site.

There's really not much to do once you get the hang of it, and our editors and staff have been enjoying using it for five years, so I hope you will too.

Here's the demo, and I really hope to get your feedback here, on github or on youtube. The first 3-4 minutes show the gist of it, so no need to sit through the full half hour if you're just curious. 👍

ARMLinker 1.0.0 released

Wed, 22 Jan 2020 23:22:41 Z

ARM What?

I've been having fun with ARM Templates the last couple of months. It's a wonderful way to keep your Azure Resource definitions in source control. Not to mention being able to parameterize deployment to different environments, and not least keeping your secrets neatly tucked away in a vault.

However, compiling a set of resources from multiple files currently requires you to put your templates online. I want to keep most of our customer products' templates private, and to do that one have to jump through hoops to copy the files over to a storage account and link to the given URLs. It kind of defeats the whole purpose for me.

So I went and created a small tool to be able to link templates locally.

How to use it

There's an installable project type for Visual Studio called "Azure Resource Group". When you create one you get a few files:

Deploy-AzureResourceGroup.ps1
azuredeploy.json
azuredeploy.parameters.json

You can stuff all of the resources you require in the azuredeploy.json file, and finally deploy them using a wizard, or run the PowerShell script in a CD pipeline.

By installing ARMLinker you can start running the tool to link other JSON files into the main azuredeploy.json file.

install-module ARMLinker

Let's say we have a Logic App (what I've been doing).
To deploy it and its connections and other needed resources, we often want a bounch of secret keys for different APIs and such.

Here's a trimmed down sample of a Logic App that runs a SQL command:

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "Tags": {
            "type": "object",
            "defaultValue": {
                "Customer": "My customer",
                "Product": "Their Logic App",
                "Environment": "Beta"
            }
        },
        "SQL-Server": {
            "defaultValue": "some.database.windows.net",
            "type": "string"
        },
        "SQL-User": {
            "defaultValue": "appuser",
            "type": "string"
        },
        "SQL-Password": {
            "defaultValue": "",
            "type": "securestring"
        },
        "SQL-Database-Name": {
            "defaultValue": "beta-database",
            "type": "string"
        }
    },
    "variables": {
        "ConnectionName": "[replace(concat(parameters('Tags').Customer, '-', parameters('Tags').Product, '-SQLConnection-', parameters('Tags').Environment), ' ', '')]",
        "LogicAppName": "[replace(concat(parameters('Tags').Customer, '-', parameters('Tags').Product, '-', parameters('Tags').Environment), ' ', '')]"
    },
    "resources": [
        {
            "type": "Microsoft.Web/connections",
            "apiVersion": "2016-06-01",
            "location": "westeurope",
            "name": "[variables('ConnectionName')]",
            "properties": {
                "api": {
                    "id": "[concat(subscription().id,'/providers/Microsoft.Web/locations/westeurope/managedApis/sql')]"
                },
                "displayName": "sql_connection",
                "parameterValues": {
                    "server": "[parameters('SQL-Server')]",
                    "database": "[parameters('SQL-Database-Name')]",
                    "authType": "windows",
                    "username": "[parameters('SQL-User')]",
                    "password": "[parameters('SQL-Password')]"
                }
            }
        }, 
        {
            "type": "Microsoft.Logic/workflows",
            "apiVersion": "2017-07-01",
            "name": "[variables('LogicAppName')]",
            "dependsOn": [ "[resourceId('Microsoft.Web/connections', variables('ConnectionName'))]" ], 
            "location": "westeurope",
            "properties": {
                "state": "Enabled",
                "definition": {
                    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
                    "contentVersion": "1.0.0.0",
                    "parameters": {
                        "$connections": {
                            "defaultValue": {},
                            "type": "Object"
                        },
                        "SQL-Server": {
                            "defaultValue": "",
                            "type": "string"
                        },
                        "SQL-Database-Name": {
                            "defaultValue": "",
                            "type": "string" 
                        }
                    },
                    "triggers": {
                        "Recurrence": {
                            "recurrence": {
                                "frequency": "Day",
                                "interval": 1
                            },
                            "type": "Recurrence"
                        }
                    },
                    "actions": {
                        "Execute_a_SQL_query_(V2)": {
                            "runAfter": {},
                            "type": "ApiConnection",
                            "inputs": {
                                "body": {
                                    "query": "select 'do something really useful' as task"
                                },
                                "host": {
                                    "connection": {
                                        "name": "@parameters('$connections')['sql']['connectionId']"
                                    }
                                },
                                "method": "post",
                                "path": "/v2/datasets/@{encodeURIComponent(encodeURIComponent(parameters('SQL-Server')))},@{encodeURIComponent(encodeURIComponent(parameters('SQL-Database-Name')))}/query/sql"
                            }
                        }
                    },
                    "outputs": {}
                },
                "parameters": {
                    "$connections": {
                        "value": {
                            "sql": {
                                "connectionId": "[resourceId('Microsoft.Web/connections', variables('ConnectionName'))]",
                                "connectionName": "variables('ConnectionName')",
                                "id": "/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.Web/locations/westeurope/managedApis/sql"
                            }
                        }
                    },
                    "SQL-Server": {
                        "value": "[parameters('SQL-Server')]"
                    },
                    "SQL-Database-Name": {
                        "value": "[parameters('SQL-Database-Name')]"
                    }
                }
            }
        }
    ]
}

The parameters here are ARM template parameters. The most interesting one is the secret password for the database server. It's secret, so it's not supposed to live in our parameter file or source control. We've also got the ID of the connection, which will be the real ID in the actual deployed Logic App.

There's a fancy way to go about keeping the password in a key vault on Azure, and the Visual Studio Wizard is really helpful with putting it into a vault.

When we're done and ready for production, a parameter file may look like this:

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "Tags": {
            "value": {
                "Customer": "My customer",
                "Product": "Their Logic App",
                "Environment": "Production"
            }
        },
        "SQL-Database-Name": {
            "value": "production-database"
        },
        "SQL-Password": {
            "reference": {
                "keyVault": {
                    "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/Vault-Group/providers/Microsoft.KeyVault/vaults/OurKeyVault"
                },
                "secretName": "CustomerSQLPassword"
            }
        }
    }
}

One of the beauties of using Logic Apps is that it have this nice GUI to work with in the portal. There's also an extension for Visual Studio to be able to edit them within Visual Studio.

However, the definition will look like this when viewed with the code editor. (I removed the bulk of it, but notice the parameters)

{
    "definition": {
        "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
        "actions": {
            "Execute_a_SQL_query_(V2)": {
                "inputs": {
                    "body": {
                        "query": "select 'do something really useful' as task"
                    },
                    "host": {
                        "..."
                    },
                    "..."
                },
                "runAfter": {},
                "type": "ApiConnection"
            }
        },
        "...",
        "parameters": {
            "$connections": {
                "defaultValue": {},
                "type": "Object"
            },
            "..."
        },
        "triggers": {
            "..."
        }
    },
    "parameters": {
        "$connections": {
            "value": {
                "sql": {
                    "connectionId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/CustomerResourceGroup/providers/Microsoft.Web/connections/MyCustomer-TheirProduct-SQLConnection-Prod",
                    "connectionName": "MyCustomer-TheirProduct-SQLConnection-Prod",
                    "id": "/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.Web/locations/westeurope/managedApis/sql"
                }
            }
        },
        "SQL-Database-Name": {
            "value": "production-database"
        },
        "SQL-Server": {
            "value": "some.database.windows.net"
        }
    }
}

Notice that the parameters are all filled out. We can't copy this into our ARM template since it's all real Resource ID references.

There's another way to get only the definition. We can use the Az.LogicApp powershell module:

(get-azlogicapp -resourcegroupname CustomerResourceGroup -name mycustomer-theirproduct-prod).definition.ToString()

It will give us only the definition part of the template.

Both gives us a means to put only the definition of the logic app into a file in our local project.

Now we can go back to the ARM template and replace the definition with a simple link to the file. Say we Set-Content the result of the statement above into a file called "logicapp.json". We can modify the ARM template as such:

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "..."
    },
    "variables": {
        "..."
    },
    "resources": [
        {
            "type": "Microsoft.Web/connections",
            "..."
        }, 
        {
            "type": "Microsoft.Logic/workflows",
            "apiVersion": "2017-07-01",
            "name": "[variables('LogicAppName')]",
            "dependsOn": [ "[resourceId('Microsoft.Web/connections', variables('ConnectionName'))]" ], 
            "location": "westeurope",
            "properties": {
                "state": "Enabled",
                "definition": {
                    "templateLink" {
                        "uri": ".\logicapp.json"
                    }
                },
                "parameters": {
                    "$connections": {
                        "value": {
                            "sql": {
                                "connectionId": "[resourceId('Microsoft.Web/connections', variables('ConnectionName'))]",
                            "connectionName": "variables('ConnectionName')",
                                "id": "/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.Web/locations/westeurope/managedApis/sql"
                            }
                        }
                    },
                    "..."
                }
            }
        }
    ]
}

By running ARMLinker we will have the same generated file as we started with, but we can use the GUI for the logic app and easily fetch the new JSON for it.

Convert-TemplateLinks azuredeploy.json azuredeploy.linked.json

For now, I've actually turned those around and put the "linked" template in a file called azuredeploy.linked.json in order to generate the "conventional" azuredeploy.json file.

More options

When using the "copy content from the editor" method mentioned above, we have to make sure to copy only the definition object. Otherwise we'll bring the concrete parameters into the local file.

Do not despair!

There's another option that doesn't match the official schema for "templateLink". By adding a property called "jsonPath" we can point to an object deeper in the linked file. Say we copy the content from the online editor.

We can modify the linked template as such:

"definition": {
    "templateLink" {
        "uri": ".\logicapp.json",
        "jsonPath": "definition"
    }
},

It will now only merge the definition part from the logicapp.json file.

I only implemented dot separated paths for now, so exotic paths to arrays or paths with special characters won't work.

IE. resources[0]['very fancy'].thing won't work, but things.with.dots will work.

Plans and dreams

This is pretty much only a workaround while waiting for Microsoft to realise this is totally useful and obvious.

I originally intended it to be a Custom Tool for Visual Studio, but I could not for the life of me figure out how to enable Custom Tools in projects not of the C# or Visual Basic archetypes.

If anyone picks up on it, I'll happily discuss new features and even happierly receive meaningful pull requests.

Other than that, I believe it does the job properly. It can be used in CD pipelines. It should even work for any JSON, not necessarily ARM templates.

I would really appreciate your feedback, and hope you like it!

Now go commit and deploy something automagically while fetching coffee! 🤘😁🦄

Code and gallery links

Github repository
PowerShell gallery

Environmental ApprovalTests

Sun, 03 Jun 2018 21:24:46 Z

Background

A while ago I wrote a post about a tool called ApprovalTests. I've included it in my workshop on unit testing Umbraco, and people are amazed at its usefulness. Having Visual Studio pop a diff in your face when stuff breaks is a real timesaver. However, when I ran the workshop at CodeGarden 18, I realized people were concerned that their tests would be impossible to run in CI environments and the like. Not to worry - ApprovalTests have you covered. (Pun intended)

Environmentalism

When declaring reporters with ApprovalTests, you can specify multiple reporters. That's not all. The reporters have an extensive API on them, which caters for us tailoring everything. There is one particularly interesting interface on all "diff-reporters" named IEnvironmentAwareReporter.
The VisualStudioReporter one has a nice little one-liner implementation:

public override bool IsWorkingInThisEnvironment(string forFile)
{
    return OsUtils.IsWindowsOs() && base.IsWorkingInThisEnvironment(forFile) && LaunchedFromVisualStudio();
}

The last function call there checks if the current process is a descendent of devenv.exe. If it isn't, execution will just be passed to the next reporter in the chain. So there! It won't break your CI build.

But what do we want in our CI build, then? Probably a regular WhateverUnit assertion. I use NUnit, so that'll be our example.

Falling back

Take this little test. I approved the result for seed 1, and we'll examine the output for an invalid result by swapping to 2:

[TestFixture]
[UseReporter(typeof(VisualStudioReporter))]
public class When_Running_In_Different_Environments
{
    [Test]
    public void Delegates_To_Most_Appropriate_Reporter()
    {
        var rnd = new Random(1);
        var items = Enumerable
            .Range(0, 10)
            .Select(x => rnd.Next());
        Approvals.VerifyAll(items, "");
    }
}

Let's change the seed to 2 to fail the test:

var rnd = new Random(2);

Now if we run the test with NUnit3-Console.exe, we'll get an exception saying that ApprovalTests can't find Visual Studio:

nunit3-console.exe .\bin\debug\environmentaltests.dll

...
1) Error : EnvironmentalTests.When_Running_In_Different_Environments.Delegates_To_Most_Appropriate_Reporter
System.Exception : Couldn't find Visual Studio at
at ApprovalTests.Reporters.GenericDiffReporter.Report(String approved, String received) in C:\code\ApprovalTests.Net\ApprovalTests\Reporters\GenericDiffReporter.cs:line 142
...

It sounds worse than it is. ApprovalTests insists that it has something to do. We can add a reporter to the fixture to fix it:

[TestFixture]
[UseReporter(typeof(VisualStudioReporter), typeof(NUnitReporter))]
public class When_Running_In_Different_Environments

Now when we run the test, we get a pure assertion failure:

1) Failed : EnvironmentalTests.When_Running_In_Different_Environments.Delegates_To_Most_Appropriate_Reporter
Expected string length 165 but was 162. Strings differ at index 6.
Expected: "[0] = 534011718\n[1] = 237820880\n[2] = 1002897798\n[3] = 165700..."
But was:  "[0] = 1655911537\n[1] = 867932563\n[2] = 356479430\n[3] = 211537..."
-----------------^

Notice it didn't even mention Visual Studio. Going back into our favorite IDE will start popping diffs again, and the NUnit one will govern the output.

Cleaning up

So should we go around declaring at least two reporters on all our fixtures, then? Luckily not. There are two more tricks that are nice to know.

First, the reporter attribute is found by iterating up the inheritance hierarchy. It can be defined as high up as all your [assembly:XAttribute] metadata. You can create a file in your test project root called ApprovalsConfig.cs for instance. Within it, you declare your reporters on the assembly level:

using ApprovalTests.Reporters;

[assembly:UseReporter(typeof(VisualStudioReporter), typeof(NUnitReporter))]

The second is that you might not want the NUnit assertion when you run in VS (for some reason), or maybe some other tool might be in your way. You might even want composite reporters. In any case, it also makes for a bit nicer setup if you implement the FirstWorkingReporter class:

public class EnvironmentReporter : FirstWorkingReporter
{
    public static readonly EnvironmentReporter INSTANCE = new EnvironmentReporter();

    public EnvironmentReporter()
        : base(
            VisualStudioReporter.INSTANCE,
            NUnitReporter.INSTANCE
        )
    {
    }
}

With it, we can change our UseReporter to be:

[assembly:UseReporter(typeof(EnvironmentReporter))]

Now the first reporter to confirm its environment is executed, and the rest are ignored. You might want to keep the NUnit one around, though. In that case, you can implement MultiReporter in the same way - which coincidentally is the same that UseReporterAttribute does.

I encourage you to go have a look at all the built-in reporters and get some inspiration for even more helpful reporting.

I'd rejoice for any cool usages in the discussion thread. :)

Morphing UCommerce Products

Tue, 30 Jan 2018 23:48:27 Z

The problem

Today I had a new but fun challenge with UCommerce. Turns out, as usual, it's a great fit for my whims with architecture. I was stuck between a rock and a hard place when I was looking at adding a custom pricing algoritm. I can't go into details, but there's custom client pricing involved of course. To add to the fun, we're mapping UCommerce products to DTOs for wire transfer. We could aslo have been mapping to view models or something else. To map we're using AutoMapper with quite a few configurations and jumps-through-hoops.

I had this code (ish):

var products = productRepository.Select().Where(SomePredicate);
var mapped = products.Select(Mapper.Map<ProductDto>);
return mapped;

I immediately thought of a few options:

Iterate over the products and change prices here
Create a Product adapter with additional logic and map from that
Execute the pricing logic from AutoMapper configuration

They all seemed weird and out of place though. None seemed like they would be easy to find for the next developer. Not even with unit tests. It just didn't seem right. Changing data on the entities would mean I'd have to go out of my way to ensure nobody went and saved those products later in the request. Creating an adapter would mean loads of new instances, bloated wrapper classes and weird names. And finally executing business logic from AutoMapper configuration means I'd been mixing responsibilities en mass.

UCommerce & NHibernate to the rescue

Luckily I've been using EntityFramework a lot and tried to force it into my Domain Driven Design patterns since it's infancy. I've been through the lot (and I enjoy it). So I kind of know what to expect from an ORM. When using UCommerce I'm stuck with NHibernate, but I haven't really been doing it justice by just leaving it in the background. (And fiddling with Entity Framework - which is just as good!) Together the two systems are extremely powerful. UCommerce have even documented the possibilities, though the documentation fails to point out the really juicy benefits.

We have ProductDefintion, right? It allows us to set up product types with different properties and variant options. It even supports inheritance. But we're still stuck with the Product class and its GetProperty() overrides. In my case, I'd like to have ProductWithFancyPricing so I could override that GetPrice() method. If I could have ProductWithFancyPricing and ProductWithEvenFancierPricing that would be totally awesome.

Turns out you can have your cake and eat it too. When properly using an ORM you can exploit OOP like it's supposed to and use polymorphism for varying behavior. It's possible to set up an inheritance tree so the mapper automatically handles creation of different types for you. You've basically got three options:

Table per concrete class (type)
- All classes have a table of their own
- Useful when base classes don't have (much) data
Table per hierarchy
- One table per base class
- Useful when all data is on the base class
Table per subclass
- One common table for base data
- Individual tables per derived class with only additional data
- Useful when there are some data in both classes. (Think umbracoNode)

In my case, I don't need any new data on the derived classes. It's all there in GetProperty() anyway. (I will add some getters though. ModelsBuilder, anyone? )
So for me it's going to be Table per hierarchy. The rest of the options are all viable for this technique if you have other requirements. You can read a bit about it in the UCommerce docs.

Mapping some product types

(I inadvertently wrote document types there. ModelsBuilder, anyone?)

In order to have NHibernate treat products as subclasses with the Table per hierarchy strategy it needs a way to pick the right class for each record. That way is known as discriminator columns. I first thought I could just discriminate by the ProductDefinitionId, but it turns out NHibernate doesn't support discriminating on a column already in use for associations (foreign keys) or other means.
We have to add a column. I just call it "Discriminator" and make it a varchar.

alter table uCommerce_Product add Discriminator nvarchar(max)

Then we need some entities. I added a couple of docu... product types:

public class ProductWithFancyPricing : UCommerce.EntitiesV2.Product
{
    public override Money GetPrice(PriceGroup priceGroup)
    {
        var price = base.GetPrice(priceGroup);
        if (IsChristmas())
        {
            price = new Money(price.Value * 2, price.Culture, price.Currency);
        }
        return base.GetPrice(priceGroup);
    }
}

public class ProductWithEvenFancierPricing : UCommerce.EntitiesV2.Product
{
    public override Money GetPrice(PriceGroup priceGroup)
    {
        var blackMarket = ObjectFactory.Instance.Resolve<IBlackMarketService>();
        var priceValue = blackMarket.GetPrice(Sku);
        return new Money(priceValue, priceGroup.Currency);
    }
}

The next thing you need is to tell NHibernate that these are our new product classes:

public class ProductWithFancyPricingMapping : FluentNHibernate.Mapping.SubclassMap<ProductWithFancyPricing>
{
    public ProductWithFancyPricingMapping()
    {
        DiscriminatorValue("Product with fancy pricing");
    }
}

public class ProductWithEvenFancierPricingMapping : FluentNHibernate.Mapping.SubclassMap<ProductWithEvenFancierPricing>
{
    public ProductWithEvenFancierPricingMapping()
    {
        DiscriminatorValue("Product with naughty pricing");
    }
}

We also need to subclass UCommerce's mapping for Product in order to tell UCommerce which column to use as the discriminator:

public class ProductMap : global::UCommerce.EntitiesV2.Maps.ProductMap
{
    public ProductMap()
    {
        DiscriminateSubClassesOnColumn("Discriminator");
    }
}

Finally we need a class in the same assembly with a tag on it. More on that in the UCommerce docs.

public class MappingMarker : IContainsNHibernateMappingsTag
{
}

To have NHibernate pick the right classes now, we just need to fix the existing products if we have any. I have called my discriminator values the same as my document types, so I can easily construct a query as such:

update
    ucommerce_product
set 
    discriminator = case productdefinitionid
        when 10 then 'Product with fancy pricing'
        when 11 then 'Product with naughty pricing'
        else null
    end

Now if we go...

var products = productRepository.Select();

...we'll get a bounch of ProductWithFancyPricings and ProductWithEvenFancierPricing. If you have more types, you might get into trouble though. You need to have a discriminator on them all.

The final hurdle

So that's cool. That's really cool. But there's one hurdle we have to jump over before we can cross the goal line. From very nasty experiences I knew I had to test everything manually and integrated. So I went and tried to see what happened if I added a product through the UCommerce Admin UI.

boom :)

'Course it didn't work. It actually did, and didn't. Several weird things happened ranging from strange NHibernate mapping exceptions to products getting the discriminator "UCommerce.EntitiesV2.Product". (Which makes a lot of sense if you think about it)

The @#¤%& CreateCategoryOrProduct.as[p|c]x WebForms control is in our way. It instantiates a Product and saves it. It's completely sealed and unconfigurable. We could overwrite it with a custom one, but that would open another can of worms with regards to upgrading, source control and what-not. Luckily it's going away very very soon in UCommerce V8. (2018?)

After hacking at it a bit my final resolve was to add a step right after save in the product saving pipeline. Again, UCommerce is so versatile that even when it sucks, it's got a golden workaround right up its arm. If you're not familiar with UCommerce Pipelines, go read about it here.

Here's the extra configuration. (In a .config file included from UCommerce's custom.config)

<!-- PRODUCT CLASS FIX -->
<component id="SaveProduct"
           service="UCommerce.Pipelines.IPipeline`1[[UCommerce.EntitiesV2.Product, UCommerce]], UCommerce"
           type="UCommerce.Pipelines.Catalog.ProductPipeline, UCommerce.Pipelines">
  <parameters>
    <tasks>
      <array>
        <value>${Product.UpdateRevision}</value>
        <value>${Product.Save}</value>
        <value>${FixProductClass}</value>
        <value>${Product.IndexAsync}</value>
      </array>
    </tasks>
  </parameters>
</component>

<component id="FixProductClass"
           service="UCommerce.Pipelines.IPipelineTask`1[[UCommerce.EntitiesV2.Product, UCommerce]], UCommerce"
           type="My.Awesome.Site.Persistence.FixProductClassTask, My.Awesome.Site.UCommerce"/>

A pipeline task gets a reference to the entity being handled, so we can't just go and replace the entire product with an instance of the right type. But we can fake it and force the database value to be correct after saving. UCommerce uses NHibernate level 2 cache, so we need to flush that as well, but we'll get to that.

Forcing the database is fairly easy. We have to resort to good old ADO code, which was actually a joyful little deja-vu experience (although I'm glad it was brief):

public class FixProductClassTask : IPipelineTask<Product>
{
    private readonly IStatelessSessionProvider sessionProvider;

    public FixProductClassTask(IStatelessSessionProvider sessionProvider)
    {
        this.sessionProvider = sessionProvider;
    }

    public PipelineExecutionResult Execute(Product subject)
    {
        var command = sessionProvider.GetStatelessSession().Connection.CreateCommand();
        command.CommandText = "UPDATE uCommerce_Product SET Discriminator = @discriminator WHERE ProductId = @productId";
        command.CommandType = CommandType.Text;
        var discriminatorParam = command.CreateParameter();
        discriminatorParam.ParameterName = "discriminator";
        discriminatorParam.Value = subject.ProductDefinition.Name;
        var idParam = command.CreateParameter();
        idParam.ParameterName = "productId";
        idParam.Value = subject.Id;
        command.Parameters.Add(discriminatorParam);
        command.Parameters.Add(idParam);
        command.ExecuteNonQuery();

        // TODO: Clear cache

        return PipelineExecutionResult.Success;
    }
}

I'm sure a lot of sazzy devs out there could prettify this a bit, but it does the job. Insert a switch/case (please don't) or whatever you fancy if the product definition name isn't what you discriminate by. I'll leave it up to you to choose between strings, ints or even enums for performance vs. readability.

If you've turned off the level 2 cache, you might be fine with this. Otherwise we'd better "evict" the entity from the cache. We need to do that in order for the cached instance to change type from Product to ProductWithFancyPricing. Sadly the NHibernate SessionFactory in charge of doing this is hidden in an internal static field in UCommerce, so we need to resort to some nasty reflection to do it:

// ...
command.ExecuteNonQuery();

var fieldInfo = typeof(SessionProvider).GetField("_factory", BindingFlags.Static | BindingFlags.NonPublic);
if (fieldInfo == null) throw new Exception("SessionFactory instance has moved in this UCommerce version. %(");
var sessionFactory = (ISessionFactory)fieldInfo.GetValue(null);
sessionFactory.Evict(typeof(Product), subject.Id);

return PipelineExecutionResult.Success;
// ...

Et voilá! We can now save new products, and they immediately morph into the correct derived type. (Except for when being saved to RavenDB for the first time, ref. the config).

I'm now free to go back into the instances and implement however naughty pricing I fancy. \o/

Added bonuses

I already have a custom entity in the database and NHibernate model. It has two associations to Product. Had I realized what I had under my fingertips it would already have been collections on my new shiny subclasses.

I recon you noticed I referenced ModelsBuilder a couple of times. How 'bout having all your properties statically typed on your product instances. How about some interfaces?

I'm sure you're getting the drift.

I for one am quite embarrased I didn't think of this before. I've had the knowledge and tools for years. But there you go. We learn something every day. And I love doing it with Umbraco, UCommerce, EntityFramework and apparently now also... NHibernate. :)

Umbraco Unit Testing Workshop Material

Thu, 09 Nov 2017 10:09:16 Z

For this years Umbraco UK Festival I was honored to be invited to run a unit testing workshop. It's a culmination of my talks and workshops until now, and covers everything you need to get going with testing the Umbraco backoffice, controller logic, external calls and finally front-end UI.

I know there's demand for this kind of training, and it might be difficult to get to the conferences where it's happening. For those of you, and those who feel bold and confident, I've released the material under the MIT license.

I can't promise I'll be able to help out if you go at it, but keep an eye out for a conference near you and encourage the organizers to host a workshop. ;)

You can clone the "workshop-start" branch from Bitbucket. The slides and workbook are included at the root of the repo.

https://bitbucket.org/bleedo/umbraco-testing-workshop-h2-2017/src/?at=workshop-start

You'll need

node
npm task runner (visual studio extension)
razorgenerator (visual studio extension)

Happy testing!

Automating Umbraco with PowerShell

Tue, 07 Nov 2017 19:46:14 Z

Background

This particular example is for warming up a UCommerce site in staging, but the technique can be used for anything you can do in the Umbraco backoffice. Especially with the new REST APIs coming out.

In this particular case, I've sinned and not created a good test environment for the last few integration bits of a project. It was hard to tune the production behavior of some code without actually running it in production. However, it's running Umbraco 7.5.13 and UCommerce 7.7. It's probably missing the other performance fix too, but the result is that it takes quite a while to warm up everything. So we warm it up in staging and then swap slots to get it fresh, awake and blazing fast into production.

Resolve

After having done this a few times, I figured I wanted something to do while waiting. What better activity than automating the whole routine so I could do something else instead? (Like automating automation...) Here's a powershell script I ended up with to warm up everything in the backoffice. I'll go through the pieces below.

Param(
    [string]$password
)

$ws = New-Object Microsoft.PowerShell.Commands.WebRequestSession

$body = @{
    "username"="admin@admin.com"
    "password"=$password
}

$json = $body | ConvertTo-Json

Invoke-RestMethod `
    -Method Post `
    -ContentType "application/json" `
    -Uri "https://customer-staging.azurewebsites.net/umbraco/backoffice/UmbracoApi/Authentication/PostLogin" `
    -WebSession $ws `
    -Body $json

Write-Host "20%"

Invoke-RestMethod -Method Get -Uri "https://customer-staging.azurewebsites.net/umbraco/ucommerce/catalog/editcategory.aspx?id=718" -WebSession $ws

Write-Host "40%"

Invoke-RestMethod -Method Get -Uri "https://customer-staging.azurewebsites.net/umbraco/ucommerce/catalog/editproduct.aspx?id=465&parentcategoryId=718" -WebSession $ws

Write-Host "60%"
Invoke-RestMethod -Method Get -Uri "https://customer-staging.azurewebsites.net/umbraco/ucommerce/settings/orders/editpaymentmethod.aspx?id=8" -WebSession $ws

Write-Host "80%"

Invoke-RestMethod -Method Get -Uri "https://customer-staging.azurewebsites.net/umbraco/ucommerce/settings/orders/editshippingmethod.aspx?id=10" -WebSession $ws
Write-Host "100%"

The effect is that we log into Umbraco using a provided password, and instead of navigating and clicking everything, we fire a request triggering all the caching and JIT compilation for us. Even though I'm using the Invoke-RestMethod cmdlet, I can do regular web calls. The cmdlet has a sibling called Invoke-WebRequest, but the rest version is better for posting commands. It's mostly a matter of mental context, but they have a few differences.

Log into Umbraco

To set up an authorized session with Umbraco, we can call the PostLogin action. It's the same endpoint that is used from the login screen. An authorized session means that we need to get a cookie and pass it with all our requests. In order for each Invoke-RestMethod to pass this cookie, we can create a WebRequestSession we pass to each call:

$ws = New-Object Microsoft.PowerShell.Commands.WebRequestSession

Invoke-RestMethod -WebSession $ws -Uri "..."

If the response brings a cookie, it's kept in the WebRequestSession, and subsequently passed back with each new request. Just like a browser.

Then we need some JSON to pass our username and password. You can declare dictionaries of sorts in PowerShell like so:

$body = @{
    "username"="admin@admin.com"
    "password"=$password
}

And then convert it to JSON by piping it to the ConvertTo-Json cmdlet:

$json = $body | ConvertTo-Json

Finally we're ready to fire the request off to Umbraco, adding config for HTTP method, ContentType etc.:

Invoke-RestMethod `
    -Method Post `
    -ContentType "application/json" `
    -Uri "https://customer-staging.azurewebsites.net/umbraco/backoffice/UmbracoApi/Authentication/PostLogin" `
    -WebSession $ws `
    -Body $json

Automate Umbraco

For this I just needed to kick off a request to some pages, but posting messages around like rebuilding a grumpy index, running an ad hoc task, even publishing should be just as simple.

It takes a while, so I added a little status message. I'm sure PowerShell wizards would pack this stuff into better reusable parts.

Write-Host "20%"

Now reuse that WebRequestSession object to fire off new authenticated requests:

Invoke-RestMethod -WebSession $ws -Method Get -Uri "https://customer-staging.azurewebsites.net/umbraco/ucommerce/catalog/editcategory.aspx?id=718"

Do it everywhere

With all the love I can give to UCommerce, I ended up naming the script kick-ucommerce.ps1. It's like kicking your old belowed car to get it started, after you've polished it. Really!
Adding my source folder to the path environment variable makes the script available from any shell. Even the Package Manager console in Visual Studio.

Make a note that the password is a parameter. You do change it more often than you'd like to update the code right? How 'bout automating the process? ;)

Smoke test and swap the Azure slot

I'll leave the swap-slot script I run after warming up the site here too. The cool thing about warming up with the script is that it'll fail almost immediately on the Umbraco login if anything isn't like it should. So it doubles as a smoke test.

When everything looks good, I can just go:

swap-slot -from staging -to production -site customer-x

And here's the "simpleness" of that one. There are fairly good docs on all the Azure cmdlets over on Microsoft's sites. (Ask Google. ;) )

Param(
    [string]$site,
    [string]$from,
    [string]$to
)

$subscriptionId = "333112F4-4483-449C-A2DA-727E8D2E428D"
$resourcegroupname = "Common-Group"     # Might need to be param

Login-AzureRmAccount -SubscriptionId $subscriptionId

Swap-AzureRmWebAppSlot `
    -SourceSlotName $from `
    -DestinationSlotName $to `
    -Name $site `
    -ResourceGroupName $resourcegroupname

That's it! Now go automate something so you get more time to do fun stuff! :)

Exploiting ApprovalTests for clearer tests

Mon, 23 Oct 2017 20:14:08 Z

What's this for?

Ever written several asserts in one test because you have a big graph you want to verify? How 'bout files or maybe razor views? Several asserts often clutter up the tests. Big strings also make the actuall calls hard to see for all that content. Putting big strings in files is a good idea to avoid that, but few people do. It adds another "menial" task when you're in the zone. But what if it was dead easy?

I once maintained a Resharper extension, and their example tests had so called "gold" files that they compared to output. The squigglies was represented by special characters around terms. So they just compared the output of a text renderer to the text in a file. Great idea. One limitation though: with a regular Assert.Equals you just see the segment around the first mismatch. Guess what, there's a tool that's been around for at least 10 years that solves all those issues, and more.

Approval tests, eh?

Sounds a bit like acceptance tests, right? Don't be fooled, it's purpose is to serve all the way down to the "unit test layer" of your tests. I've found it to be a huge timesaver, as well as making my tests so much more clear.

I know you're thinking "Shut up and give me an example, then!", so let's have a look. I've got this unit test from my post about testing razor views that I never really asserted anything in. I just output the result to console and assert inconclusive. Here it is for reference:

[TestFixture]
public class When_Displaying_An_Event
{
    [Test]
    public void It_Is_Rendered_With_A_Name_Date_And_A_Link()
    {
        var view = new _Views_Partials_Event_cshtml();
        var actionResult = GetConcertEvent();

        Assert.AreEqual("Event", actionResult.ViewName);

        var renderedResult = view.Render((Event) actionResult.Model);

        Console.WriteLine(renderedResult);
        Assert.Inconclusive("Way too big to assert here.");
    }
}

It outputs the following HTML:

<div>
    <a href="https://eventsite/123">
        <label>
            Concert of your life
        </label>
        <span>
            fredag 31. desember 2049 23.59
        </span>
    </a>
</div>

Let's see it

Now let's assert this with ApprovalTests. To use it, you just install-package ApprovalTests with your trusty package manager console. Make sure to install it in your test project. ;)

Now instead of Assert, we ask ApprovalTests to Verify our data instead. It even has a special overload for this concrete case: Approvals.VerifyHtml. So we rewrite the test as such:

[Test]
public void It_Is_Rendered_With_A_Name_Date_And_A_Link()
{
    var view = new _Views_Partials_Event_cshtml();
    var actionResult = GetConcertEvent();

    Assert.AreEqual("Event", actionResult.ViewName);

    var renderedResult = view.Render((Event) actionResult.Model);

    Approvals.VerifyHtml(renderedResult);
}

Now when we run our test, we get this nice little welcoming message from ApprovalTests:

It tells us we're missing a vital part: A reporter. It's possible to use DiffReporter to launch your favorite configured difftool. But if you're in Visual Studio, there's a special treat: VisualStudioReporter. Let's add that to our fixture and see what happens:

[UseReporter(typeof(VisualStudioReporter))]
[TestFixture]
public class When_Displaying_An_Event
{
    [Test]
    public void It_Is_Rendered_With_A_Name_Date_And_A_Link()
    {
        // ...
    }
}

And we run it:

What hits you is probably the big failure statement there, but look again - up at the top there. We've got a diff opened, the result on the left hand and a big green field on the right side.
What just happened is that ApprovalTests took our result, stored it in a received file, and at the same time wrote an empty "approved" file. It then proceeded to compare, and finally pop a diff of those two files.
Isn't that just beautiful? Everything that makes your test fail in one clear diagram.

The "procedure to follow" here, is to "approve" results when you're happy. To do that, you just copy and paste. Let's do that now:

If you've got ReSharper, it's probably gonna try to format everything nicely when you paste. To have it in the original, ugly indentation state, press Ctrl+Z (undo) once after pasting.

Regarding the indentation that's off. It seems to be a bug with HTML in the current version of ApprovalTests, so stupid me for choosing this example. I'll update the post if it gets fixed.

We can now run our test again, and it's gonna pass. When it passes, it doesn't bother to open the diff.

This means we're just gonna get diffs for whatever is currently failing. Even if we run our entire suite of tests. Now there's a couple of housekeeping things to keep in mind:

Commit approvals only

If you were paying attention, you noticed we got two files adjacent to our test source file. One is named [TestFixtureName].[TestMethodName].received.html and one is named [TestFixtureName].[TestMethodName].approved.html. If you ran a test that passed, you'll actually just have your approved file. You want those approved files in source control!

The received files though, might end up not being cleaned up for one or the other reason. Hopefully just that you didn't bother to commit a fully passing build. I'm sure you didn't do that to the master branch, though. In any case, make sure to ignore your received files. This pattern in .gitignore generally does the trick:

*.received.*

That's just the tip of the iceberg

We've seen the VerifyHtml bit. One of my personal favorites is it's sibling VerifyJson. I keep an extension on object in my tests, called .ToJson(). With it, I can just go:

Approvals.VerifyJson(myBigGraph.ToJson());

The diff is done with prettified JSON, so it's super simple to find the property / area that has changed or doesn't work. Knowing the area of the graph should also make it easier to find the usage that is wrong.

There's a vanilla Verify method too, and it saves plain text files. It's useful in cases where you have nice ToString() implementations. Let's try with a "person":

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }

    public override string ToString()
    {
        return $"{FirstName} {LastName} ({Age})";
    }
}

[Test]
public void Comparing_Objects()
{
    var person = new Person
    {
        FirstName = "Lars-Erik",
        LastName = "Aabech",
        Age = 19
    };

    Approvals.Verify(person);
}

It produces the following .received file:

Lars-Erik Aabech (19)

It can be approved like that.
We can also do lists with "big brother" VerifyAll:

[Test]
public void Comparing_Lists()
{
    var list = new List<Person>
    {
        new Person {FirstName = "Lars-Erik", LastName = "Aabech"},
        new Person {FirstName = "Dear", LastName = "Reader"}
    };

    Approvals.VerifyAll(list, "");
}

Which, unsurprisingly outputs:

[0] = Lars-Erik Aabech
[1] = Dear Reader

Now how bout that?
I don't know how quickly you got hooked, but I certainly find it sneaking into more and more of my tests.

It can even do images, but I'll let James blog about that one.

So what are you lingering around here for? Run over to nuget and get your copy, or lurk around some more at the ApprovalTests project site. There's great examples, even though they might not be in your favorite language.

Happy approving! :)

UmbracoSupport got typed content

Tue, 17 Oct 2017 21:18:06 Z

What's UmbracoSupport?

UmbracoSupport is a class I've been introducing to my unit tests over the last year or so. It allows me to have my own hierarchy for tests, as well as re-using all of Umbraco's own stubbing code. I've written about it in a post called Unit testing Umbraco just got simpler, and its gut's code is described in details in The basics of unit testing Umbraco.

A quick primer on what's already available

The BaseDatabaseFactoryTest in Umbraco.Tests has a method called GetXmlContent. It replaces the umbraco.config file that acts as the cache at runtime. It makes UmbracoContext.Current.ContentCache tick in unit tests. The base tests out of the box has a small flaw though. They can't "popuplate" properties. All you get is the hierarchy.

Usually I've injected an IPublishedContentCache to my controllers. When testing them, I've created a mock instance of the IPublishedContentCache. However, all my code has to use the non-context aware overloads. For instance cache.GetById(umbracoContext, false, id). There's also a whole lot of ugly mocking code going on to set up queries and stubbed content. How to stub properties on stubbed content is described in Slides from CG 2016 and testing IPublishedContent properties.

So what's new?

As mentioned, I've been throwing around all kinds of ugly stubbing code for content and I've also been tampering with Umbraco.Tests's GetXmlContent() to use the "built-in" content stubs. It's all been done before in misc. tests in Umbraco. I finally got my s**t together and refactored all my setup spaghetti into a few small helpers on the UmbracoSupport class.

Let's go over them in increasing "integrationness".

Pure hierarchy

Your basic hierarchy structure can be set up by simply returning a string from an overload of BaseDatabaseFactoryTest.GetXmlContent. UmbracoSupport overloads this method and returns whatever you've set on the UmbracoSupport.ContentCacheXml property. I recommend using the technique described in Automating creating of source data for tests with this. You can even extend that code to have fixture specific content caches.

In any case, to make this work, you just need to set the XML in the setup method.

Note: I've got some probs with the markdown parsing here, imagine the CDATA parts of the XML is correctly written.

[SetUp]
public void Setup()
{
    umbracoSupport = new UmbracoSupport();
    umbracoSupport.SetupUmbraco();

    // This XML is what the ContentCache will represent
    umbracoSupport.ContentCacheXml = @"
        <?xml version=""1.0"" encoding=""utf-8""?>
        <!DOCTYPE root [
          <!ELEMENT contentBase ANY>
          <!ELEMENT home ANY>
          <!ATTLIST home id ID #REQUIRED>
          <!ELEMENT page ANY>
          <!ATTLIST page id ID #REQUIRED>
        ]>
        <root id=""-1="""">
          <home id=""1103="""" key=""156f1933-e327-4dce-b665-110d62720d03="""" parentID=""-1="""" level=""1="""" creatorID=""0="""" sortOrder=""0="""" createDate=""2017-10-17T20:25:12="""" updateDate=""2017-10-17T20:25:17="""" nodeName=""Home="""" urlName=""home="""" path=""-1,1103="""" isDoc="""" nodeType=""1093="""" creatorName=""Admin="""" writerName=""Admin="""" writerID=""0="""" template=""1064="""" nodeTypeAlias=""home="""">
            <title>Welcome!</title>
            <excerptCount>4</excerptCount>
            <page id=""1122="""" key=""1cb33e0a-400a-4938-9547-b05a35739b8b="""" parentID=""1103="""" level=""2="""" creatorID=""0="""" sortOrder=""0="""" createDate=""2017-10-17T20:25:12="""" updateDate=""2017-10-17T20:25:17="""" nodeName=""Page="" 1="""" urlName=""page1="""" path=""-1,1103,1122="""" isDoc="""" nodeType=""1095="""" creatorName=""Admin="""" writerName=""Admin="""" writerID=""0="""" template=""1060="""" nodeTypeAlias=""page="""">
              <title>Welcome!</title>
              <excerpt>[CDATA[Lorem ipsum dolor...]]</excerpt>
              <body>
                [CDATA[<p>Lorem ipsum dolor...</p>]]
              </body>
              <image>123</image>
            </page>
            <page id=""1123="""" key=""242928f6-a1cf-4cd3-ac34-f3ddf3526b2e="""" parentID=""1103="""" level=""2="""" creatorID=""0="""" sortOrder=""1="""" createDate=""2017-10-17T20:25:12="""" updateDate=""2017-10-17T20:25:17="""" nodeName=""Page="" 2="""" urlName=""page2="""" path=""-1,1103,1123="""" isDoc="""" nodeType=""1095="""" creatorName=""Admin="""" writerName=""Admin="""" writerID=""0="""" template=""1060="""" nodeTypeAlias=""page="""">
              <title>More welcome!</title>
              <excerpt>[CDATA[More lorem ipsum dolor...]]</excerpt>
              <body>[CDATA[Even more lorem ipsum dolor...]]</body>
              <image>234</image>
            </page>
          </home>
        </root>
    ".Trim();
}

In our tests, we can now query by anything. The returned content has the hierarchy and everything, so we can traverse it with Children(), Parent() and whatnot. The only missing piece is the properties. Here's a test showing that we have everything but the title property of Page 1:

const int Page1Id = 1122;

[Test]
public void Returns_Empty_Documents()
{
    var contentCache = umbracoSupport.UmbracoContext.ContentCache;
    var page1 = contentCache.GetById(Page1Id);

    Assert.That(page1, Is
        .Not.Null
        .And
        .InstanceOf<PublishedContentWithKeyBase>()
        .And
        .Property("Name").EqualTo("Page 1")
        .And
        .Matches<IPublishedContent>(c => c["title"] == null)
        .And
        .Property("Parent")
            .Property("Children")
                .With.Count.EqualTo(2)
    );
}

Don't be discouraged though. This method is excellent for testing URL providers, ContentFinders, Menus, Sitemaps. You name it. I know I've written my fair share of hierarchy traversing code or fancy XPath queries. Unless of course, you need property values.

Instead of pulling your leg about it, here's how we fix that.

Put some meat on the content

The reason the properties are not there isn't because they weren't read. It's because the XmlPublishedContent that we get out ultimately relies on the PublishedContentType for it's respective document type. Luckily, all Umbraco's services are already stubbed up for us, so we can give it what it needs.

The gory guts of it is that it needs an IContentType from the ContentTypeService. We can easily stub one up with Moq: var contentType = Mock.Of<IContentType>(). Further, it uses the IContentType.CompositionPropertyTypes collection to iterate the properties. These PropertyType instances are actually completely dependency-less, so we can just create some:

Mock.Get(contentType)
    .Setup(t => t.CompositionPropertyTypes)
    .Returns(new[] {
        new PropertyType("Umbraco.TinyMCEv3", DataTypeDatabaseType.Nvarchar, "body")
    });

Finally, we set it up on the ContentTypeService stub:

Mock.Get(umbracoSupport.ServiceContext.ContentTypeService)
    .Setup(s => s.GetContentType(alias))
    .Returns(contentType);

If only it were so easy. We depend on the BaseWebTest class from Umbraco.Tests. It sets up a content type factory that's being used somewhere in the hierarchy. It feeds AutoPublishedContent instances instead of what we've stubbed up. We need to turn that off. There's a trick here. UmbracoSupport should now live in an assembly called Umbraco.UnitTests.Adapter. If you're pre 7.6.4 you need to go with Umbraco.VisualStudio. This is because the factory we need to reset is internal to Umbraco. By having UmbracoSupport in an assembly with one of these two names, we're able to do it. (Otherwise, you use reflection.) By no means do this with production code. Just... forget it!
This paragraph should also get it's own blog post. :)

But I digress. Here's the line you need to have the content use the ContentTypeService to fetch its type:

PublishedContentType.GetPublishedContentTypeCallback = null;

It's tempting to leave setup code like this lying around in all our SetUp methods or even in our "Arrange" sections. I've sinned too much, so those few lines are now part of UmbracoSupport and can be used to set up multiple types for your fixture or test.

Here's a test that fetches the same document as before, but can now read properties:

[Test]
public void With_DocumentTypes_Setup_Returns_Full_Blown_Documents()
{
    umbracoSupport.SetupContentType("page", new[]
    {
        new PropertyType("textstring", DataTypeDatabaseType.Nvarchar, "title"),
        new PropertyType("textarea", DataTypeDatabaseType.Nvarchar, "excerpt"),
        new PropertyType("Umbraco.TinyMCEv3", DataTypeDatabaseType.Nvarchar, "body"),
        new PropertyType("media", DataTypeDatabaseType.Integer, "image")
    });

    var page1 = contentCache.GetById(Page1Id);

    Assert.Multiple(() =>
    {
        Assert.That(page1["title"], Is.EqualTo("Welcome!"));
        Assert.That(page1["excerpt"], Is.EqualTo("Lorem ipsum dolor..."));
        Assert.That(page1["body"].ToString(), Is.EqualTo("<p>Lorem ipsum dolor...</p>"));
        Assert.That(page1["image"], Is.EqualTo(123));
    });
}

Notice the .ToString() on the body. It's actually not a string, but some weird dynamic Umbraco thingy. I never saw that type before, but I didn't pursue it in time for this post. I don't want anything to do with it though, so let's storm on to the grand finale.

Let's make them strong already!

We're finally there. The last piece of the puzzle. Strongly typed content!

It's managed by two resolvers: PublishedContentModelFactoryResolver and PropertyValueConvertersResolver. I won't go into details about those now, but suffice to say all resolvers have to be initialized before BaseWebTest.Initialize and its ancestors. I've added an InitializeResolvers method to the UmbracoSupport class where these two are initialized. The PublishedContentModelFactoryResolver is set to a FakeModelFactoryResolver that lets you register constructors for document type aliases. The code for this is available in my "Umbraco unit testing samples" repo on github.

To set up property value converters, we also need to do that before registering the resolver. The resolver takes all the converters as constructor arguments. I've added a list of those types as a property on UmbracoSupport, so we can add IPropertyValueConverter implementing types before calling UmbracoSupport.SetupUmbraco:

[SetUp]
public void Setup()
{
    umbracoSupport = new UmbracoSupport();

    // Converter types need to be added before setup
    umbracoSupport.ConverterTypes.Add(typeof(TinyMceValueConverter));

    umbracoSupport.SetupUmbraco();

    //...
}

To register the typed model, there's just one line you can do in your setup, or even in your tests. Here I've refactored out the setup for the content type from earlier, and I register a model type for the document type alias:

private void SetupContentType()
{
    umbracoSupport.SetupContentType("page", new[]
    {
        new PropertyType("textstring", DataTypeDatabaseType.Nvarchar, "title"),
        new PropertyType("textarea", DataTypeDatabaseType.Nvarchar, "excerpt"),
        new PropertyType("Umbraco.TinyMCEv3", DataTypeDatabaseType.Nvarchar, "body"),
        new PropertyType("media", DataTypeDatabaseType.Integer, "image")
    });
}

[Test]
public void With_DocumentTypes_And_Models_Setup_Returns_Fully_Functional_Typed_Content()
{
    SetupContentType();

    // Register strongly typed models with the ModelFactory
    umbracoSupport.ModelFactory.Register("page", c => new Page(c));

    var page1 = contentCache.GetById(Page1Id);

    Assert.That(page1, Is
        .InstanceOf<Page>()
        .And.Property("Body")
            .Matches<IHtmlString>(s => 
                s.ToString() == "<p>Lorem ipsum dolor...</p>"
            )
    );
}

public class Page : PublishedContentModel
{
    public Page(IPublishedContent content) : base((IPublishedContentWithKey)content)
    {
    }

    public string Title => Content.GetPropertyValue<string>("title");
    public string Excerpt => Content.GetPropertyValue<string>("excerpt");
    public IHtmlString Body => Content.GetPropertyValue<IHtmlString>("body");
    public int Image => Content.GetPropertyValue<int>("image");
}

There you go! There's nothing more to it. Well, there is...

The Page class here is bundled with the test. If we use a common interface both for our runtime model and our test model, we're safe. But we should really use the runtime models. This means you shouldn't use runtime generated models. Go through the instructions for ModelsBuilder to have your models compiled and accessible from the tests.

Conclusion

And although the XML is pretty ugly, you can flush it out into files bundled with your tests. You can also exploit the umbraco.config file and just copy segments from there into your test source files. That way, you spend no time writing the stubs, and the content is cleanly separated from your tests.

That's really all there is to it! It is. Now go test a bit, or a byte, or a string, or even a view.

The new version of UmbracoSupport including the fake model factory is available here.

Testing views with RazorGenerator

Mon, 09 Oct 2017 21:08:20 Z

Razor what?

RazorGenerator is a hidden gem that lets you generate and pre-compile what would otherwise be generated and compiled at runtime. Your Razor. Not only does it give you a startup time boost, but it lets you unit test your views. The latter is the focus of this post.

We'll continue to build on the project I described in my post on generating documentation with NUnit. It's a simple use case where an imaginary CMS has a feature to display events from a third party site. Here are the tests I've got so far:

In my previous post, I left the rendering test inconclusive. I like keeping inconclusive tests around as reminders of stuff I've got left to do. Let's have a quick look at the passing code before we dive into the rendering bits.

Basic HTTP integration and conversion tests

The first large piece of what's in there for now is a way to remove the physical dependency on the third party site. I like to stub away IO as far out as I can so I can test as much of my code quickly, yet as integrated as possible. In other words, as many participating classes as possible. Since we're making an example here, I'm just using the HttpClient directly from the controller. The HttpClient is hard to mock or fake, but it has an inner dependency that we can pass as an argument to a constructor: HttpMessageHandler. It has the innermost function that the HttpClient uses for any operation. It also has the rare trait of being protected virtual, so we can stub it out. For this example, I'm just using a fake one that records requests and returns responses for registered URLs. Here it is:

public class FakeMessageHandler : HttpMessageHandler
{
    private readonly Dictionary<string, string> responses = new Dictionary<string,string>();
    public List<string> Calls { get; } = new List<string>();

    public void Register(string url, string response)
    {
        responses.Add(url, response);
    }

    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        var url = request.RequestUri.ToString();

        Calls.Add(url);

        if (!responses.ContainsKey(url))
        { 
            return Task.FromResult(new HttpResponseMessage
            {
                StatusCode = HttpStatusCode.NotFound,
                Content = new StringContent("{}")
            });
        }

        return Task.FromResult(new HttpResponseMessage
        {
            Content = new StringContent(responses[url])
        });
    }
}

We'll not dwell further on this one in this post, but you'll need it to run the following examples if you want to tag along.

The tests that verifies that we call the right URL on the third party site is pretty simple. It checks the Calls collection on the FakeMessageHandler. Here's the test and the setup code needed:

[TestFixture]
public class When_Displaying_An_Event
{
    [Test]
    [DocumentationOrder(0)]
    [Description(@"
    Events are provided at eventsite with a REST api at the URL:
    https://eventsite/api/{id}
    ")]
    public void It_Is_Fetched_By_Id_From_The_Event_Server()
    {
        eventController.Event(234).Wait();

        Assert.AreEqual(
            "https://eventsite/api/234", 
            httpMessageHandler.Calls.Single()
        );
    }

    // ... omitted other tests

    [SetUp]
    public void Setup()
    {
        httpMessageHandler = new FakeMessageHandler();
        httpClient = new HttpClient(httpMessageHandler);
        eventController = new EventController(httpClient);
    }

    private FakeMessageHandler httpMessageHandler;
    private HttpClient httpClient;
    private EventController eventController;
}

And the controller:

public class EventController : Controller
{
    private readonly HttpClient httpClient;

    public EventController(HttpClient httpClient)
    {
        this.httpClient = httpClient;
    }

    public async Task<PartialViewResult> Event(int id)
    {
        var requestUri = "https://eventsite/api/" + id;
        var result = await httpClient.GetAsync(requestUri);
        var response = await result.Content.ReadAsStringAsync();
        // ... omitted further processing for now
    }
}

We pass the FakeMessageHandler instance to a new HttpClient effectively making it a stub. We can control the response for individual URLs, and verify that the right ones were called.

Next step is to convert it to a valid model we can use in our view. We've got a second test asserting that:

[Test]
[DocumentationOrder(1)]
[Description("The JSON response from the event server is deserialized as the Event type.")]
public void It_Is_Converted_To_An_Event_Model()
{
    var result = GetConcertEvent();
    var model = (Event)result.Model;

    Assert.AreEqual("Concert of your life", model.Name);
    Assert.AreEqual(new DateTime(2049,12,31,23,59,59), model.Time);
    Assert.AreEqual("https://eventsite/123", model.Url);
}

private PartialViewResult GetConcertEvent()
{
    httpMessageHandler.Register(
        "https://eventsite/api/123",
        "{\"name\":\"Concert of your life\", \"time\":2524607999}"
    );

    var result = eventController.Event(123).Result;
    return result;
}

And here's the rest of the controller code creating that model:

public async Task<PartialViewResult> Event(int id)
{
    var requestUri = "https://eventsite/api/" + id;
    var result = await httpClient.GetAsync(requestUri);
    var response = await result.Content.ReadAsStringAsync();
    var eventJObj = JsonConvert.DeserializeObject<JObject>(response);
    var evt = new Event
    {
        Name = eventJObj.Value<string>("name"),
        Time = DateTimeOffset.FromUnixTimeSeconds(eventJObj.Value<long>("time")).DateTime,
        Url = "https://eventsite/" + id
    };
    return PartialView("Event", evt);
}

The test is a tedious verification of every property on the event object. There are several ways to get around that. Amongst others, equality members. I've got a way better trick, but that's for an upcoming post.

Now that we're through those tests, let's dive into how we can test the actual HTML output of this whole shenanigan.

Generating some Razor

As mentioned initially, RazorGenerator is a hidden gem in the ASP.NET OSS wilderness. There's a Visual Studio plugin that you need to exploit it fully. It's aptly called RazorGenerator and can be installed from here. There's also a couple of Nuget packages that we want:

RazorGenerator.Mvc
Referenced in your website to make use of a special ViewEngine for pre-compiled views.
RazorGenerator.Testing
Referenced in our test projects to be able to automagically render views in tests.

Armed with these tools, there's nothing left to do but add a custom tool to our view:

As soon as you've blured the "Custom Tool" field, a .cs file will be generated beneath the view. Upon inspection it yields a class in the ASP namespace making a whole lot of Write* statements. This is what clutters up your ASP.NET Temporary files all the time. And the nice part: it can be instantiated.

Here's the initial markup from Event.cshtml:

@model Example.WebSite.Models.Event

<div>
    <a href="@Model.Url">
        <label>
            @Model.Name
        </label>
        <span>
            @Model.Time.ToString("f")
        </span>
    </a>
</div>

Over in our unit test, we can now start adding some actual rendering of HTML:

[Test]
[DocumentationOrder(2)]
public void It_Is_Rendered_With_A_Name_Date_And_A_Link()
{
    var view = new _Views_Partials_Event_cshtml();
    var result = GetConcertEvent();

    Assert.AreEqual("Event", result.ViewName);

    var renderedResult = view.Render((Event) result.Model);

    Console.WriteLine(renderedResult);
    Assert.Inconclusive("Rendering has not been implemented yet.");
}

private PartialViewResult GetConcertEvent()
{
    httpMessageHandler.Register(
        "https://eventsite/api/123",
        "{\"name\":\"Concert of your life\", \"time\":2524607999}"
    );

    var result = eventController.Event(123).Result;
    return result;
}

I know, the view type name ain't too pretty. But it's necessary for the view engine to find the right one based on the path given. The cool part is the Render statement. It's an extension method from the RazorGenerator.Tests package. It returns the final HTML as a string.

The Console.WriteLine statement yields the following in our test output now:

<div>
    <a href="https://eventsite/123">
        <label>
            Concert of your life
        </label>
        <span>
            fredag 31. desember 2049 23.59
        </span>
    </a>
</div>

(Yes, I force my locale upon thee!)

What we've just done is to test our system almost end to end, cut off at the uttermost borders to external IO. Specifically, the third party site and the end-user's browser.

Granted, we could do Selenium tests here to really test it via the browser, but my rule of thumb is that RazorGenerator is the best choice unless you've got a lot of JavaScript interactivity you need to test in integration. These are subjects for another post.

There is a remaining issue though. We should assert the HTML we got rendered. We could store that HTML we got in a const string expected in our test, but it's gonna foul up the code quite a bit. We could go with so-called "gold files" and implement something to compare a file to the actual output. There's a magical tool for that called ApprovalTests, which I'll cover in my next post.

There's also the option of using HtmlAgilityPack to query the rendered view. The RazorGenerator.Tests package have built-in alternative for Render called RenderAsHtml that returns HtmlDocument instances for you to query. It's quite useful when your only Assert.That is for some specific element in a big page.

Resources and a small limitation

You've seen how you can use RazorGenerator to test your views. There are several posts by David Ebbo (one of the authors of RazorGenerator) on how to use RazorGenerator. Please check them out for more details than I was able to give here.

For now it doesn't do nested Html.Action or Html.Partial calls. I've got a PR in the works, but I need to polish it for it to get in there. Some day soon. ;) If you really want to, you'll find my fork and build your own, but you'll be on your own.

There's also a tiny performance hit. You'll have to wait a second longer for your tests to execute, since a lot of the ASP.NET MVC framework is spun up to render views. It's still less than the magical 2 second focus cap though, so you should be able to work effectively with it.

I hope this piqued your interest in writing broader tests even up to the UI layers. There's even cooler tricks in store for you if you're already on .net Core, but the rest of us will have to make due until then.

Generating documentation from NUnit tests

Sun, 08 Oct 2017 21:06:26 Z

What's the catch?

There's a lot of benefits with unit testing. One of the less exploited ones would be documentation. I've heard it said, and I've said it myself countless times: Unit Tests can be used as documentation. They are inherently documentation by being a good place to look for sample code. But what if they could also serve as actual go-to documentation, a backlog, a technical specification and all those things that otherwise go rot in a Word document on some server?

Lately, I've been experimenting with generating good documentation from NUnit tests for our ASP.NET MVC sites. (Based on Umbraco CMS, but that's not important to this article.)
I've been baffled by the lack of good information when I've googled for NUnit result transformations. So I gave it a go, and I'll share some techniques with you in this post.

Many unit tests won't do for documentation though. I believe that testing should be done as integrated as possible, stopping just before they become slow. This allows for more user-centric, or holistic descriptions of the system. I'm doing my best to get better at naming them. They should read like stories describing the system. That way it'll be easy for other devs to find the right code to extend or debug. Namespacing and organization play a strong role, as well as good, descriptive names. It's hard, but I believe striving for this might actually also aid in the ability to use them as documentation.

An example

So for this example, let's have a look at a pretty simple case. We're integrating with a third-party event site to display relevant events on pages in our site. We have some kind of module that lets editors pick events and place them in pages. The part I'll use in this post is the part about fetching and displaying it.

The tests I'm writing are feature specific, but technical enough in nature to belong in the realm of technical documentation. For business targeted documentation, you're better off looking into BDD and all the practices that follows. If you don't have the team though, you might be able to get something working for you with the following techniques.

Here's the test output I've got so far:

I think it reads fairly well. There shouldn't be too much doubt what this feature does. Granted, it's a really simple one, and complex systems will have thousands. Even more reason to group by feature, and add areas and other useful grouping levels as namespaces.

You'll also notice I've got a test that is inconclusive saying not implemented. I've started doing this to keep a kind of backlog of things to do. It's easy to forget about technical debt or rarer cases we've ignored. Having inconclusive tests glaring at you makes it easy to remember. It may also serve as a discussion point to bring up with the customer. "Should we bother to handle this weird case? It'll increase the budget with $...".

There are still a couple of readability issues in the tests. When we add more features, it'd be nice to find all event-related tests in their own group. That's a quick fix. We'll add a namespace. (Put common tests in the same folder)

There's also a matter of order. Obviously fetching from server happens before converting to a model and then rendering it. There are concepts like ordered tests, but I believe atomic tests are faster and more flexible. I've got a solution for that, but let's live with it for now.

Having this output from the testrunner or on the build server, even in your inbox when someone commits, is useful. We have a broad overview of what the system does. The tests names are decoupled from any implementation details so we're free to change the architecture while keeping our descriptive tests.

But we could do more.

NUnit console runner output

When working on code, we use built-in test runners in our IDEs. We're able to run one or a few test in isolation and focus on just the right things. Build servers use command line runners and ususally produce some form of textual or HTML output. We can exploit the CLI tools as well. The NUnit console runner outputs an XML format by default. You can even do it from the package manager console in Visual Studio like so:

PM> .\packages\NUnit.ConsoleRunner.3.7.0\tools\nunit3-console.exe .\NUnitDocs.Tests\bin\debug\NUnitDocs.Tests.dll

If you're using Nuget to organize your dependencies, you can install the NUnit.ConsoleRunner package to get the executable in the packages folder. Otherwise, you can download it from the NUnit downloads page.

In addition to logging the results to the output, NUnit will write some metadata, and the following (more interesting) to TestOutput.xml:

<test-run id="2" testcasecount="3" result="Passed" total="3" passed="2" failed="0" inconclusive="1" >

  <!-- Attributes and metadata elements stripped for clarity -->

  <test-suite type="TestSuite" id="0-1005" name="NUnitDocs" fullname="NUnitDocs" runstate="Runnable" testcasecount="3" result="Passed" total="3" passed="2" failed="0" warnings="0" inconclusive="1">
    <test-suite type="TestSuite" id="0-1006" name="Tests" fullname="NUnitDocs.Tests">
      <test-suite type="TestSuite" id="0-1007" name="Events" fullname="NUnitDocs.Tests.Events">
        <test-suite type="TestFixture" id="0-1000" name="When_Displaying_An_Event" fullname="NUnitDocs.Tests.Events.When_Displaying_An_Event">
          <test-case id="0-1002" name="It_Is_Converted_To_An_Event_Model" fullname="NUnitDocs.Tests.Events.When_Displaying_An_Event.It_Is_Converted_To_An_Event_Model" methodname="It_Is_Converted_To_An_Event_Model" classname="NUnitDocs.Tests.Events.When_Displaying_An_Event" runstate="Runnable" seed="1189788506" result="Passed" start-time="2017-10-08 19:44:11Z" end-time="2017-10-08 19:44:12Z" duration="0.413085" asserts="3" />
          <test-case id="0-1001" name="It_Is_Fetched_By_Id_From_The_Event_Server" fullname="NUnitDocs.Tests.Events.When_Displaying_An_Event.It_Is_Fetched_By_Id_From_The_Event_Server" methodname="It_Is_Fetched_By_Id_From_The_Event_Server" classname="NUnitDocs.Tests.Events.When_Displaying_An_Event" runstate="Runnable" seed="486335788" result="Passed" start-time="2017-10-08 19:44:12Z" end-time="2017-10-08 19:44:12Z" duration="0.001595" asserts="1" />
          <test-case id="0-1003" name="It_Is_Rendered_With_A_Name_Date_And_A_Link" fullname="NUnitDocs.Tests.Events.When_Displaying_An_Event.It_Is_Rendered_With_A_Name_Date_And_A_Link" methodname="It_Is_Rendered_With_A_Name_Date_And_A_Link" classname="NUnitDocs.Tests.Events.When_Displaying_An_Event" runstate="Runnable" seed="804806648" result="Inconclusive" start-time="2017-10-08 19:44:12Z" end-time="2017-10-08 19:44:12Z" duration="0.015905" asserts="0">
            <reason>
              <message>
                <![CDATA[Rendering has not been implemented yet.]]/>
              </message>
            </reason>
          </test-case>
        </test-suite>
      </test-suite>
    </test-suite>
  </test-suite>
</test-run>

I know, I know. It's not cool anymore. I don't like it any more than you, but there is one durable ancient technology we could use to do something with this output. Did you guess it yet?

XSLT!

There. I said it.

Now let's look at a simple output before we dive into the more beefy things:

Now ain't that starting to look readable? There's not that much to it. The NUnit console runner has a built-in parameter with the syntax --result=SPEC, where SPEC can point to an XSLT sheet. Here's the command to generate the former:

.\packages\NUnit.ConsoleRunner.3.7.0\tools\nunit3-console.exe .\NUnitDocs.Tests\bin\debug\NUnitDocs.Tests.dll  --result:"TestSummary.htm;transform=TestSummary.xslt"

The XSLT isn't much either. There's Bootstrap and (our trusty) JQuery from CDN. Some simple HTML formatting. And I wrote a one-liner JavaScript function to strip out all the underscores as well. Here's the first pass:

<?xml version="1.0" encoding="iso-8859-1"?>
<xsl:stylesheet
    version="1.0"
    exclude-result-prefixes="msxsl"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:msxsl="urn:schemas-microsoft-com:xslt"
    >
  <xsl:output method="html" indent="yes"/>

  <xsl:template match="@* | node()">
    <html>
      <head>
        <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" crossorigin="anonymous"/>
        <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap-theme.min.css" integrity="sha384-rHyoN1iRsVXV4nD0JutlnGaslCJuC7uwjduW9SVrLvRYooPp2bWYgmgJQIXwl/Sp" crossorigin="anonymous"/>
        <style type="text/css">
          .Passed { color: green; }
          .Inconclusive { color: #BBAA00; }
          .Failed { color: red; }

          ul {
          margin-left: 0px;
          list-style-type: none;
          padding-left: 0;
          }

          ul ul {
          margin-left: 15px;
          }

          .counts {
          font-size: .7em;
          color: gray;
          }
        </style>

      </head>
      <body>
        <div class="container">
          <xsl:apply-templates select="/test-run/test-suite"/>
        </div>
        <script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js" integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa" crossorigin="anonymous">// Force closing tag</script>
        <script src="https://code.jquery.com/jquery-3.2.1.slim.min.js">// Force closing tag</script>
        <script type="text/javascript">
          $("td").each(function(i, e) {
          $(e).text($(e).text().replace(/_/g, " "));
          });
        </script>
      </body>
    </html>
  </xsl:template>

  <xsl:template match="/test-run/test-suite">
    <h1>
      <xsl:value-of select="./test-run/@name"/>
    </h1>
    <table class="table table-striped">
      <xsl:apply-templates select="./test-suite"/>
    </table>
  </xsl:template>

  <xsl:template match="test-suite">
    <tr>
      <td>
        <xsl:attribute name="class">
          <xsl:choose>
            <xsl:when test="./@failed > 0">Failed</xsl:when>
            <xsl:when test="./@inconclusive > 0">Inconclusive</xsl:when>
            <xsl:otherwise>Passed</xsl:otherwise>
          </xsl:choose>
        </xsl:attribute>
        <xsl:attribute name="style">
          padding-left: <xsl:value-of select="count(ancestor::test-suite)*15"/>px;
        </xsl:attribute>
        <xsl:value-of select="./@name"/>
      </td>
      <td class="counts">
        <xsl:value-of select="./@passed"/> passed,
        <xsl:value-of select="./@inconclusive"/> inconclusive,
        <xsl:value-of select="./@failed"/> failed
      </td>
    </tr>
    <xsl:for-each select="./test-suite">
      <xsl:apply-templates select="."/>
    </xsl:for-each>
    <xsl:for-each select="./test-case">
      <xsl:apply-templates select="."/>
    </xsl:for-each>
  </xsl:template>

  <xsl:template match="test-case">
    <tr>
      <td colspan="2">
        <xsl:attribute name="style">
          padding-left: <xsl:value-of select="count(ancestor::test-suite)*15"/>px;
        </xsl:attribute>
        <xsl:attribute name="class">
          <xsl:value-of select="./@result"/>
        </xsl:attribute>
        <xsl:value-of select="./@name"/>
      </td>
    </tr>

  </xsl:template>
</xsl:stylesheet>

This is fairly good as a starting point, but we're stuck with the brief test names. Having some free text, at least at feature level or use-case level would be nice. And we still have this ordering problem to deal with. NUnit has the perfect tool for this:

NUnit PropertyAttribute

NUnit comes with a PropertyAttribute that we can use to decorate our tests with metadata. It's main purpose is to add properties to fixtures and tests in the test output. It's an abstract class we can use to create our own metadata, and there's a few built-in like DescriptionAttribute. There are uses of properties at runtime too, but that's way too advanced for this post.

The DescriptionAttribute is just what we want for the free text part of our documentation. It's added to the method just like the Test attribute:

[Test]
[Description(@"
Events are provided at eventsite with a REST api at the URL:
https://eventsite/api/{id}
")]
public void It_Is_Fetched_By_Id_From_The_Event_Server()
{
    // ...
}

[Test]
[Description("The JSON response from the event server is deserialized as the Event type.")]
public void It_Is_Converted_To_An_Event_Model()
{
    // ...
}

The Description is written to the XML output like so:

<test-case id="0-1002" name="It_Is_Converted_To_An_Event_Model" ...>
    <properties>
        <property name="Description" value="The JSON response from the event server is deserialized as the Event type." />
    </properties>
</test-case>

By adding a few more voodoo lines to the XSLT and another one-liner JavaScript, we get the following output:
(Don't worry, complete XSLT is available at the bottom fo the post.)

Now we're really getting somewhere. We can provide that little extra that tells the reader what's really happening and stuff that might be obscured by too many, or hopefully just the right amount of abstractions.

Let's tackle the ordering problem while we're at it.

Implementing our own properties

The PropertyAttribute isn't much more than a metadata container. An ordering property is as simple as such:

public class DocumentationOrderAttribute : PropertyAttribute
{
    public DocumentationOrderAttribute(int order)
        : base("DocumentationOrder", order)
    {
    }
}

It's applied to the tests just like the descriptions:

[Test]
[DocumentationOrder(0)]
[Description(@"
Events are provided at eventsite with a REST api at the URL:
https://eventsite/api/{id}
")]
public void It_Is_Fetched_By_Id_From_The_Event_Server()
{
    // ...
}

And it's output just like descriptions:

<test-case id="0-1002" name="It_Is_Converted_To_An_Event_Model" ...>
    <properties>
        <property name="DocumentationOrder" value="1" />
        <property name="Description" value="The JSON response from the event server is deserialized as the Event type." />
    </properties>
</test-case>

Now we can tackle the ordering problem with a simple XSLT sort element:

<xsl:for-each select="./test-case">
  <xsl:sort select="./properties/property[@name='DocumentationOrder']/@value"/>
  <xsl:apply-templates select="."/>
</xsl:for-each>

And we get a nice ordered output:

Summary

By structuring and naming our tests by feature we get nice headings for potential documentation. We also untie them completely from implementation so we're free to change our code. Applying a bit of metadata to our tests adds that little extra to make quite meaningful documentation.

The fact that the results can be tranformed means we can create rich documentation UIs with search, tags, navigation structure and a bit less than just enough prose.

Next steps

We've still got that rendering test to pass. There's also a few too many asserts in one of the tests. In an upcoming post I'll share a couple of other tools with you and how to extend those to enrich the technical documentation even more.

Complete XSLT

Here's the complete XSLT for the examples above:

<?xml version="1.0" encoding="iso-8859-1"?>
<xsl:stylesheet
    version="1.0"
    exclude-result-prefixes="msxsl"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:msxsl="urn:schemas-microsoft-com:xslt"
>
  <xsl:output method="html" indent="yes"/>

  <xsl:template match="@* | node()">
    <html>
      <head>
        <!-- Latest compiled and minified CSS -->
        <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" crossorigin="anonymous"/>
        <!-- Optional theme -->
        <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap-theme.min.css" integrity="sha384-rHyoN1iRsVXV4nD0JutlnGaslCJuC7uwjduW9SVrLvRYooPp2bWYgmgJQIXwl/Sp" crossorigin="anonymous"/>
        <style type="text/css">
          .Passed { color: green; }
          .Inconclusive { color: #BBAA00; }
          .Failed { color: red; }

          ul {
          margin-left: 0px;
          list-style-type: none;
          padding-left: 0;
          }

          ul ul {
          margin-left: 15px;
          }

          label {
          font-weight: normal;
          }

          .counts {
          font-size: .7em;
          color: gray;
          }
        </style>

      </head>
      <body>
        <div class="container">
          <xsl:apply-templates select="/test-run/test-suite"/>
        </div>
        <!-- Latest compiled and minified JavaScript -->
        <script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js" integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa" crossorigin="anonymous">// Force closing tag</script>
        <script src="https://code.jquery.com/jquery-3.2.1.slim.min.js">// Force closing tag</script>
        <script type="text/javascript">
          $("td label").each(function(i, e) {
          $(e).text($(e).text().replace(/_/g, " "));
          });
          $(".description").each(function(i, e) {
          $(e).html($(e).html().trim().replace(/\n/g, '<br/>'));
          });
        </script>
      </body>
    </html>
  </xsl:template>

  <xsl:template match="/test-run/test-suite">
    <h1>
      <xsl:value-of select="./test-run/@name"/>
    </h1>
    <table class="table table-striped">
      <xsl:apply-templates select="./test-suite"/>
    </table>
  </xsl:template>

  <xsl:template match="test-suite">
    <tr>
      <td>
        <xsl:attribute name="class">
          <xsl:choose>
            <xsl:when test="./@failed > 0">Failed</xsl:when>
            <xsl:when test="./@inconclusive > 0">Inconclusive</xsl:when>
            <xsl:otherwise>Passed</xsl:otherwise>
          </xsl:choose>
        </xsl:attribute>
        <xsl:attribute name="style">
          padding-left: <xsl:value-of select="count(ancestor::test-suite)*15"/>px;
        </xsl:attribute>
        <xsl:value-of select="./@name"/>
      </td>
      <td class="counts">
        <xsl:value-of select="./@passed"/> passed,
        <xsl:value-of select="./@inconclusive"/> inconclusive,
        <xsl:value-of select="./@failed"/> failed
      </td>
    </tr>
    <xsl:for-each select="./test-suite">
      <xsl:apply-templates select="."/>
    </xsl:for-each>
    <xsl:for-each select="./test-case">
      <xsl:sort select="./properties/property[@name='DocumentationOrder']/@value"/>
      <xsl:apply-templates select="."/>
    </xsl:for-each>
  </xsl:template>

  <xsl:template match="test-case">
    <tr>
      <td colspan="2">
        <xsl:attribute name="style">
          padding-left: <xsl:value-of select="count(ancestor::test-suite)*15"/>px;
        </xsl:attribute>
        <label>
          <xsl:attribute name="class">
            <xsl:value-of select="./@result"/>
          </xsl:attribute>
          <xsl:value-of select="./@name"/>
        </label>
        <xsl:if test="./properties/property[@name='Description']">
          <div class="description">
            <xsl:value-of select="./properties/property[@name='Description']/@value"/>
            <xsl:text> </xsl:text>
          </div>
        </xsl:if>

      </td>
    </tr>

  </xsl:template>
</xsl:stylesheet>

Potential freeze with Umbraco and SignalR

Fri, 23 Jun 2017 22:16:38 Z

I cloned the Umbraco 7.7 dev branch today to prepare a demo for my colleagues next week. SignalR has been bundled with Umbraco, and guess what - problems I've had before hit me again. It just freezes on boot, specifically at the app.MapSignalR call in the Owin startup.

Turns out, the HQ guys have already been down this road and helped fix a really really weird bug with it. Read the issue and Stephane's post, it's quite interesting. But this was not the issue that hit me, even tho it's quite similar in behavior.

I've actually been down this road before myself. I recalled having had similar problems. I didn't dive into it back then, I just gave up and threw SignalR out. I'd like to say I have just as deep an analysis as Stephane has in his post, but I'm just not as good. :) In any case, it's something to do with the performance counters reading a registry key.

The code is somewhere within PerformanceCounter.NextSample(). My debugging symbols fu is not strong enough to get everything right there, but it's somewhere in the PerformanceCounterLib and has something to do with a RegistryKey being read. I had it in the stacktrace, but I'm sorry to say I didn't record it.

Popping the registry editor, I find it already focused on a registry key called SignalR. I'm guessing I haven't had it open since I gave up the last time. Again, sorry for not having deeper knowledge here. You might have a gazillion keys called SignalR-something.vstemplate. These are safe, but the one only named SignalR is our suspect. I impatiently went ahead and deleted it, and now everything works.

So I'm stuck trying to provide any deeper knowledge, and I was stupid enough not to record the key name before I threw it out. Although, I'm pretty sure it is from the SignalR performance counters, and that the key in question is HKLM\System\CurrentControlSet\Services\SignalR\Performance. I threw the whole SignalR key out.

If I gain any deeper knowledge, I'll update this post. Otherwise, at least you know that deleting that key may save your day. :)

Copying Umbraco datatype settings (prevalues).

Tue, 18 Apr 2017 12:25:17 Z

I had to copy a grid with settings and our "default template" settings today. Given there's no copy datatype feature in Umbraco yet, I had the option of ticking all the boxes manually, or invent a quicker way. So I ended up just doing a quick hack in SQL to do the work for me. I'm mostly putting it here for my own reference for later, but maybe - just maybe it's useful for you too. :)

If you create a new datatype with the same property editor in the backoffice, you can compare it's settings with an existing one as such:

select
    *
FROM 
    cmsDataTypePreValues target
    inner join cmsDataTypePreValues source  on 
        source.datatypenodeId = 1048 and target.datatypenodeid = 1630
        and
        source.alias = target.alias

Just swap out 1038 and 1630 with your respective source values. If you run the query you'll see that we'd like the values on the right to be copied to the left ones. That's just a matter of running and update. Wrap it in a transaction just to check that you don't update 1000 prevalues inadvertently:

begin tran
go

update target set 
    target.value = source.value
FROM 
    cmsDataTypePreValues target
    inner join cmsDataTypePreValues source  on 
        source.datatypenodeId = 1048 and target.datatypenodeid = 1630
        and
        source.alias = target.alias

go
rollback tran

If it says it updated as many rows as you have settings, you're in the green and can swap the rollback tran to a commit tran and there you go. All settings copied.

Now all we've got to do is wrap this in a WebAPI call and we've almost got the copy/paste datatypes feature in Umbraco. :)

Automating creation of source data for tests

Thu, 06 Apr 2017 10:11:09 Z

I'm writing some tests for a synchronization job between two systems at the moment. Especially for these kinds of projects, but also most other, I need to have a fair amount of test-data to spin off useful tests.

The worst way of doing this is building up huge object graphs in setup methods. I guess an even worse way is to set up big object graphs using mocks, setting up each property. I've seen and probably did both, but it basically just makes you stop testing if you can't find another way.

So I've learned to move such test-data out into separate files. Often in a "TestData" folder or the like. Naming gets a bit random, but at least it's better.

But after starting to use ApprovalTests by Llewellyn Falco, I got inspired by the way it magically adds received and approved files named after specific tests. It's quite genious. And the best part is that NUnit more or less supports everything you need to do so in other situations.

Let's say I have this test and some test-data:

[TestFixture]
public class When_Updating
{
    [Test]
    public void Then_Posts_Data()
    {
        var arr = JsonConvert.DeserializeObject<JArray>(Path.Combine(
            AppDomain.CurrentDomain.BaseDirectory,
            @"TestData\some-test-file.json"
         ));
        // ... test stuff
    }
}

I could extract this into a helper and pass "TestData\some-test-file.json" perhaps. But it could be even better. NUnit has this TestContext singleton that holds the current fixture and test names. (Amongst other things.) We can use this to our advantage. Have a look at this helper:

private static T ReadTestSource<T>()
    where T : new()
{
    var sourceFileName = Type.GetType(TestContext.CurrentContext.Test.ClassName)?.Name + "." + TestContext.CurrentContext.Test.MethodName + ".Source.json";
    var filePath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, @"..\..", sourceFileName);
    if (!File.Exists(filePath))
        using (var file = File.CreateText(filePath))
            file.Write(JsonConvert.SerializeObject(new T()));
    return JsonConvert.DeserializeObject<T>(File.ReadAllText(filePath));
}

Given this, we can replace the entire test-data getter to a single parameterless (generic, tho) method:

[TestFixture]
public class When_Updating
{
    [Test]
    public void Then_Posts_Data()
    {
        var arr = ReadTestSource<JArray>();
        // ... test stuff
    }
}

If I did this in a completely fresh test, I would actually get a JSON file on disk, called "When_Updating.Then_Posts_Data.Source.json". Since I passed JArray as the generic parameter, the file will already contain []. If it were an object, it'd have all the keys. I can just start filling it out. In this case, I've got another slower integration test I can copy some data from, and I'll have my source data at hand.

There's more magic that could be done, but I found these 9 lines of code so cool and powerful not to go ahead and share it at once. :) One important thing missing is finding the tests folder, but I'm sure you're up for that challenge if you find this useful.

Happy testing!

[Edit] I really, really needed that namespace/test-folder pretty soon, so here's a non-refactored method that does just that. :)

private static T ReadTestSource<T>()
    where T : new()
{
    var rootPath = Path.GetFullPath(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, @"..\.."));
    var type = Type.GetType(TestContext.CurrentContext.Test.ClassName);
    var path = type?.Namespace?.Replace(type.Assembly.GetName().Name + ".", "").Replace(".", "\\");
    var testFolder = Path.Combine(rootPath, path ?? "");
    if (!Directory.Exists(testFolder))
        throw new Exception("Need to keep namespace and folder in sync to create test-source file");
    var sourceFileName = type?.Name + "." + TestContext.CurrentContext.Test.MethodName + ".Source.json";
    var filePath = Path.Combine(testFolder, sourceFileName);
    if (!File.Exists(filePath))
        using (var file = File.CreateText(filePath))
            file.Write(JsonConvert.SerializeObject(new T()));
    return JsonConvert.DeserializeObject<T>(File.ReadAllText(filePath));
}

The basics of unit testing Umbraco just got simpler

Sat, 18 Mar 2017 22:21:23 Z

Status Quo of Umbraco Testing 2017

It's been a year since giving my presentation about Unit Testing Umbraco at Codegarden 2016. Testing Umbraco is ever more popular, and I'm happy to see there's more people talking about it on twitter, at festivals and at gatherings. Recently, Christian Thillemann decided he was tired of waiting for the request I created last year about having Umbraco.Tests on Nuget. He went ahead and set up an AppVeyor script and we now have automatic releases of Our.Umbraco.Community.Tests on nuget whenever there's a new Umbraco version out. #H5YR, @kedde! :)

Of course, having this requirement and having to lean that heavily on an external assembly just to get to annoying internals in our core product is just an intermediate challenge. Come Umbraco 9 on .net Core, we'll (hopefully) be able to just spin up a complete hosted Umbraco site from our tests and inject / swap out whatever we'd fancy in that startup. Java and other platforms has had that option for years, so it's about time the .net community gets there. But enough ranting about that, let's just keep contributing so we get closer to running on .net Core.

Meanwhile...

In the mean time, I've been exploring further practices with automated testing. I'll get back to those in future posts and presentations. But while doing this, I stubled into an alternative practice to the one I've been preaching. It's mostly the same, but it challenges the inherital structure of Umbraco.Tests.

A really good principle when you write tests is letting your tests be interfaces to your code. Whenever you write a user interface, you take good care putting your logic in separate classes. The UI stuff is just UI stuff. Maybe our tests should be like that too? When you do that, you can even re-use your tests for different layers of your code! I'll not go into details about that in this post, but a natural result was to offload everything about Umbraco into its own class. I don't know why I didn't before, or why it took me so long to do it, but I suppose it's got something to do with closed mentality. When you see a pattern (inherited unit-tests), you automatically think it's a good one, and don't challenge it.

An epiphany

If you've gone through my post about the basics of testing Umbraco, you know you can inherit quite a few different base tests from Umbraco.Tests. They all have their uses, and I still recommend using the BaseDatabaseFactoryTest if you're testing stuff integrated with a database. However, most of what I write are different Surface-, Render- and *ApiControllers using fairly few stubbable things. All the front-end ones have the same basic initial state needs, and the backoffice ones just have fewer. So we end up inheriting BaseRoutingTest and calling GetRoutingContext(...) in all our setups. Being the smart devs you are, I'm sure a lot of you also ended up with some kind of MyUmbracoTestBase.

But there's something completely wrong with that! We're letting the dependency on Umbraco get in the way of our own automation code. We can't create a hirarchy of tests that isn't dependent on Umbraco. For instance, if we had a base class initializating our own domain in our core domain tests, we couldn't re-use that for our MVC tests. To do that we'd have to inherit our core base test class from Umbraco tests, and then Umbraco would leak into our core domain. We don't want that.

The solution

SRP your tests of course! Excercise the same dicipline by applying nice layering to your test automation code as you do to your other code. I ended up refactoring most of my test classes' setups and teardowns into a "Support" class with only three public methods. Here's how you'd set up a test for a simple SurfaceController with this method:

[TestFixture]
public class Adding_Numbers
{
    private UmbracoSupport support = new UmbracoSupport();

    [SetUp]
    public void Setup()
    {
        support.SetupUmbraco();
    }

    [TearDown]
    public void TearDown()
    {
        support.DisposeUmbraco();
    }

    [Test]
    public void Posting_AddModel_Calculates_Result()
    {
        const int expectedSum = 3;
        var controller = new SimpleSurfaceController();
        var result = (AdditionModel)controller.Add(1, 2);
        Assert.AreEqual(expectedSum, result.Model.Sum);
    }
}

I want to stress that this is not, and will not be a package. See below for reasons.

So it isn't that different from inheriting BaseRoutingTest. The only difference is that we delegate the setup and teardown to another type instance instead of delegating it to the base class. The UmbracoSupport class still derives from BaseRoutingTest, but it stops there. It won't leak further.

Note that NUnit creates an instance of your test fixture for each test, so you'll get a fresh UmbracoSupport instance for each of your tests.

The third method you'd want to call is PrepareController(). The moment you'd like to act upon the CurrentPage, or just use RedirectToCurrentUmbracoPage, you'll have to call support.PrepareController(controller). This wires up the Umbraco request context instance to your controller's state.

When you've done that, you've got quite a few properties on the support class that let's you get to the juicy stuff you'll want to stub:

Property	Purpose
`UmbracoContext`	The current `UmbracoContext`. Inject it to your controllers and whatnot
`ServiceContext`	The complete `IServiceContext` with clean stubs
`CurrentPage`	A mock of the currently served `IPublishedContent`. Same as `UmbracoContext.Current.PublishedRequestContext.PublishedContent`, `UmbracoHelper.AssignedContentItem` and `SurfaceController.CurrentPage`.
`RouteData`	You might hit further usage of this internally to Umbraco. It's available for modification when you do
`HttpContext`	The good ol' "testable" `HttpContextBase` from MVC, created along with the `UmbracoContext`.

The implementation

I've already implemented this class in the umbraco-unit-testing-samples repo. I'll post it here as well for you to copy uncritically. I won't go through the details. It's just a refactored version of what I've shown in previous posts.

using System;
using System.Globalization;
using System.Web;
using System.Web.Mvc;
using System.Web.Routing;
using Moq;
using Umbraco.Core;
using Umbraco.Core.Configuration.UmbracoSettings;
using Umbraco.Core.Models;
using Umbraco.Core.Persistence;
using Umbraco.Core.Services;
using Umbraco.Tests.TestHelpers;
using Umbraco.Web;
using Umbraco.Web.Mvc;
using Umbraco.Web.Routing;

namespace Umb.Testing.Tests.Support
{
    public class UmbracoSupport : BaseRoutingTest
    {
        public UmbracoContext UmbracoContext => umbracoContext;

        public new ServiceContext ServiceContext => serviceContext;

        public IPublishedContent CurrentPage => currentPage;

        public RouteData RouteData => routeData;

        public UmbracoHelper UmbracoHelper => umbracoHelper;

        public HttpContextBase HttpContext => umbracoContext.HttpContext;

        public string ContentCacheXml { get; set; }

        /// <summary>
        /// Initializes a stubbed Umbraco request context. Generally called from [SetUp] methods.
        /// Remember to call UmbracoSupport.DisposeUmbraco from your [TearDown].
        /// </summary>
        public void SetupUmbraco()
        {
            InitializeFixture();
            TryBaseInitialize();

            InitializeSettings();

            CreateCurrentPage();
            CreateRouteData();
            CreateContexts();
            CreateHelper();

            InitializePublishedContentRequest();
        }

        /// <summary>
        /// Cleans up the stubbed Umbraco request context. Generally called from [TearDown] methods.
        /// Must be called before another UmbracoSupport.SetupUmbraco.
        /// </summary>
        public void DisposeUmbraco()
        {
            TearDown();
        }

        /// <summary>
        /// Attaches the stubbed UmbracoContext et. al. to the Controller.
        /// </summary>
        /// <param name="controller"></param>
        public void PrepareController(Controller controller)
        {
            var controllerContext = new ControllerContext(HttpContext, RouteData, controller);
            controller.ControllerContext = controllerContext;

            routeData.Values.Add("controller", controller.GetType().Name.Replace("Controller", ""));
            routeData.Values.Add("action", "Dummy");
        }

        protected override string GetXmlContent(int templateId)
        {
            if (ContentCacheXml != null)
                return ContentCacheXml;

            return base.GetXmlContent(templateId);
        }

        private UmbracoContext umbracoContext;
        private ServiceContext serviceContext;
        private IUmbracoSettingsSection settings;
        private RoutingContext routingContext;
        private IPublishedContent currentPage;
        private RouteData routeData;
        private UmbracoHelper umbracoHelper;
        private PublishedContentRequest publishedContentRequest;

        protected override ApplicationContext CreateApplicationContext()
        {
            // Overrides the base CreateApplicationContext to inject a completely stubbed servicecontext
            serviceContext = MockHelper.GetMockedServiceContext();
            var appContext = new ApplicationContext(
                new DatabaseContext(Mock.Of<IDatabaseFactory>(), Logger, SqlSyntax, GetDbProviderName()),
                serviceContext,
                CacheHelper,
                ProfilingLogger);
            return appContext;
        }

        private void TryBaseInitialize()
        {
            // Delegates to Umbraco.Tests initialization. Gives a nice hint about disposing the support class for each test.
            try
            {
                Initialize();
            }
            catch (InvalidOperationException ex)
            {
                if (ex.Message.StartsWith("Resolution is frozen"))
                    throw new Exception("Resolution is frozen. This is probably because UmbracoSupport.DisposeUmbraco wasn't called before another UmbracoSupport.SetupUmbraco call.");
            }
        }

        private void InitializeSettings()
        {
            // Stub up all the settings in Umbraco so we don't need a big app.config file.
            settings = SettingsForTests.GenerateMockSettings();
            SettingsForTests.ConfigureSettings(settings);
        }

        private void CreateCurrentPage()
        {
            // Stubs up the content used as current page in all contexts
            currentPage = Mock.Of<IPublishedContent>();
        }

        private void CreateRouteData()
        {
            // Route data is used in many of the contexts, and might need more data throughout your tests.
            routeData = new RouteData();
        }

        private void CreateContexts()
        {
            // Surface- and RenderMvcControllers need a routing context to fint the current content.
            // Umbraco.Tests creates one and whips up the UmbracoContext in the process.
            routingContext = GetRoutingContext("http://localhost", -1, routeData, true, settings);
            umbracoContext = routingContext.UmbracoContext;
        }

        private void CreateHelper()
        {
            umbracoHelper = new UmbracoHelper(umbracoContext, currentPage);
        }

        private void InitializePublishedContentRequest()
        {
            // Some deep core methods fetch the published content request from routedata
            // others access it through the context
            // in any case, this is the one telling everyone which content is the current content.

            publishedContentRequest = new PublishedContentRequest(new Uri("http://localhost"), routingContext, settings.WebRouting, s => new string[0])
            {
                PublishedContent = currentPage,
                Culture = CultureInfo.CurrentCulture
            };

            umbracoContext.PublishedContentRequest = publishedContentRequest;

            var routeDefinition = new RouteDefinition
            {
                PublishedContentRequest = publishedContentRequest
            };

            routeData.DataTokens.Add("umbraco-route-def", routeDefinition);
        }
    }
}

Why no package?

You might be wondering why I didn't package this up into a nice reusable nuget package for y'all to install. It's because THIS ISN'T IT! It isn't a silver bullet. It's boilerplate. You're bound to want to add your own varying states and preconditions to this setup. If I'd packaged it, we'd need an "OnThis", "OnThat" and "OnWhatever" for everything that happens so you could extend it. I've done several PRs to the core to have Umbraco.Tests usable as it is now, and I don't want to create another such layer.

You might for instance have to fiddle a bit with CreateApplicationContext(), and I'm quite sure that any sligtly advanced site will have to have tests setting up stuff in FreezeResolution(). That'd be solvable with inheritance, but here we go again... ;)

Next up

There's a few doors that open when you extract everything out of your tests. I'm dying to show you more, but I'll have to leave a lame "to-be-continued" and hope I don't mess it up. Happy refactoring, and do go get that nuget package from @kedde!

Rather Package Manager Console than Print?

Fri, 17 Feb 2017 11:30:32 Z

I don't know about you, but I printed my last sheet of code sometime during the mid-nineties. Yet when you press Ctrl+P in Visual Studio, guess what happens? You may print your code! I don't think I ever did that. If I ever printed a class diagram, I must have used the File->Print menu item anyway.

What I do use often though, is the Nuget Package Manager Console. It bothered me that the console is purely for keyboard input, but you have to use the mouse to get to it. And Eureka! What better shortcut to get to the package manager console than Ctrl+P?

I know Ctrl+P is the recommended shortcut for printing across Windows (Command+P on mac?), but come on! I've gone and added a feature request on uservoice.visualstudio.com, though I guess the recommendation beats usefulness.

You can still do it

If you know your way around Visual Studio and think this is a good idea, I guess you've already customized your environment. If you don't know how to do it, here's how:

Open the Tools menu and select Options.
Navigate to Environment\Keyboard
Under "Show commands containing", search for "View.PackageManagerConsole"
Under "Press shortcut keys", hit Ctrl+P
Click "Assign"

And there you go, you're ready to pop the package manager console with Ctrl+P.

How to kill Umbraco with UrlRewrite.Net

Mon, 09 Jan 2017 22:03:53 Z

The case

Recently we were contacted by another Norwegian company who inherited a custom Umbraco solution. The original developer is off chasing green fields, so they came to us when the site restarted twice an hour. Something about CPU spikes... It had been upgraded to 7.5.4 and everything, so we could just start off clicking all the shiny new buttons in the health dashboard. Most "known" Azure fixes were already in place, and the rest was applied for good measure. Yet the problem persisted, so we knew we were facing a more dire problem.

The proof

Jumping onto the Azure graphs and logs, we could see a pattern of massive memory usage as well as the CPU. Here's a nice bouncy graph of the state of the S3(!) server.

Going through the Umbraco logs, we found several restarts due to out of memory exceptions from seemingly unrelated calls. All of them seemed to correlate with the restarts and massive resource spikes. Some of them came from cached views, so we did an attemt to remove caching from the most varied pages. After all, Umbraco already has the content in memory, so how much CPU goes into rendering it? It was quickly dismissed though, the problem persisted.

We'd also spotted another suspect in the logs, namely UrlRewrite.Net. But at this point we were also ready to throw some profiling tools on the site. Somehow, none of JetBrains' tools worked. For some reason the views could not be rendered. I suspect it has something to do with the caching, profiling views or how the tools work. But I digress. We were able to run VS' profiler on it, and guess who turned up as our main suspect again?

I think the table speaks for it self. The upper two calls are in idling background threads. They don't affect CPU at all. Having the system access the database for one second is within limits for several requests. But the rest of the CPU time was actually spent solely in UrlRewrite.Net and parsing of regular expressions. I could quickly verify we weren't the first seeing this after searching our.umbraco.org too.

The fix

Now don't go panic over your own UrlRewrites just yet. This site had more than 2.500 rewritten URLs buried in urlrewrite.config. After being made aware, our contractor cut it down to 150 more generalized regular expressions, and voila, there's been a steady 3% CPU usage since then.

I've been sceptical to people bad-mouthing UrlRewrite.Net in the past. We've never had many problems with it in our sites. But then again, we've never gone past 50 rewrite rules. (I think.) It's a great tool for its purpose, but as we've now witnessed, it can also do great harm when used wrong. It might be time for us to throw out the old IIS 6 servers and start using Microsoft's Url Rewrite Module instead.

Alternatives

But what should we do, then, when faced with situations where we have thousands of URLs to keep 301'ing? I'd guess you've got some kind of pattern there so you can simplify with catching regular expressions like we did here. Otherwise, you're probably better off writing your own small HttpModule with some logic, rather than relying on generic rewriters and regex.