JasperFx Software is officially ready to provide formal paid support for Marten, Wolverine, or any other JasperFx dependency of the previous two tools. Starting now, potential users can feel safe in adopting Marten or Wolverine for mission critical applications knowing that there’s a backing company ready to support them in their usage of these tools.

Check out our support plans today and please feel free to contact us at sales@jasperfx.net with any questions or hop onto the JasperFx Software Discord channel and we’ll be happy to chat with what may or may not make sense for your shop.

This is an important step for us to make the Critter Stack a viable platform over the long term for our users. Our long term goal is to make the “Critter Stack” the single best set of tooling for creating server side applications in .NET in general and more specifically the best tooling for building solutions with Event Sourcing and CQRS on any platform.

In the future, we’ll also be announcing add on products for the Critter Stack tools that will provide advanced usages and deployment strategies including:

• Zero downtime deployments
• A blue/green deployment capability
• Enhanced scalability for the Marten event store functionality
• Management consoles for Wolverine messaging, dead letter queue management, and Marten event storage and projection oversight

We would like to thank our vibrant community for all of your support, encouragement, and enthusiasm over these past years since Marten arrived on the scene in 2016. We look forward to engaging with you all as we have embarked on building a sustainable business model around these tools.

Just a coincidence here, but I had this blog post draft in the works right as my friend and Critter Stack collaborator Oskar Dudycz wrote Is the Strategy Pattern an ultimate solution for low coupling? last week (right after Lillard was traded). My goal here is just to create some new blog content by plucking out existing usages of design patterns in my own work. I’m hoping this turns into a low key series to go revisit some older software development concepts and see if they still hold any value.

On Design Patterns

Before discussing the “Strategy Pattern,” let’s go address the obvious elephant in the room. There has been a huge backlash against design patterns in the aftermath of the famous “Gang of Four” book. As some of you will be unable from resist pointing out in the comments, design patterns have been absurdly overused by people who associate complexity in code with well engineered code leading to such atrocities as “WidgetStrategyAbstractFactoryBuilder” type names showing up in your code. A certain type of very online functional programming enthusiast loves to say “design patterns are just an indication that your OO programming language is broken and my FP language doesn’t need them” — which I think is both an inaccurate and completely useless statement because there are absolutely recurring design patterns in functional programming as well even if they aren’t the exact same set of design patterns or implemented the exact same way as they were described in the old GoF book from the C++ era.

Backing off of the negativity and cynicism, “design patterns” came out of a desire to build a taxonomy and understanding of reoccurring structural elements that developers were already frequently using to solve problems in code. The hope and goal of this effort was to build a common language that developers could use with each other to quickly describe what they were doing when they used these patterns or even to just understand what some other developer was doing in the code you just inherited. Just as importantly, once we developers have a shared name for these patterns, we could start to record and share a body of wisdom about when and where these patterns were applicable, useful, or harmful.

That’s it, that’s all they ever should have been. The problems always came about when people decided that design patterns were recommendations or goals unto themselves and then tried to maximize their usage of said patterns. Software development being very prone to quick cycles of “ooh, shiny object!” then the inevitable backlash after taking the new shiny object way too far, design patterns got an atrocious reputation across much of our community.

After all that being said, here’s what I think is absolutely still valuable about design patterns and why learning about them is worth your time:

• They happen in code anyway
• It’s useful to have the common language to discuss code with other developers
• Recognizing a design pattern in usage can give you some quick insight into how some existing code works or was at least intended to work
• There is a large amount of writing out there about the benefits, drawbacks, and applicability of all of the common design patterns

And lastly, don’t force the usage of design patterns in your code.

The Strategy Pattern

One of the simplest and most common design patterns in all of software development is the “Strategy” pattern that:

allows one of a family of algorithms to be selected on-the-fly at runtime.

Gang of Four

Fine, but let’s immediately move to a simple, concrete example. In a recent Wolverine release, I finally added an end to end multi-tenancy feature for Wolverine’s HTTP endpoints for a JasperFx client. One of the key parts of that new feature was for Wolverine to be able to identity what the active tenant was from an HTTP request. From experience, I knew that there were several commonly used ways to do that, and even knew that plenty of folks would want to mix and match approaches like:

• Look for a named route argument
• Look for an expected request header
• Use a named claim for the authenticated user
• Look for an expected query string parameter
• Key off of the Url sub domain name

And also allow for users to add some completely custom mechanism for who knows what they’ll actually want to do in their own system.

This of course is a pretty obvious usage of the “strategy pattern” where you expose a common interface for the variable algorithms that could be used within the code that ended up looking like this:

/// <summary>
/// Used to create new strategies to detect the tenant id from an HttpContext
/// for the current request
/// </summary>
public interface ITenantDetection
{
    /// <summary>
    /// This method can return the actual tenant id or null to represent "not found"
    /// </summary>
    /// <param name="context"></param>
    /// <returns></returns>
    public ValueTask<string?> DetectTenant(HttpContext context);
}

Behind the scenes, a simple version of that interface for the route argument approach looks like this code:

internal class ArgumentDetection : ITenantDetection
{
    private readonly string _argumentName;

    public ArgumentDetection(string argumentName)
    {
        _argumentName = argumentName;
    }

    public ValueTask<string?> DetectTenant(HttpContext httpContext)
    {
        return httpContext.Request.RouteValues.TryGetValue(_argumentName, out var value) 
            ? new ValueTask<string?>(value?.ToString()) 
            : ValueTask.FromResult<string?>(null);
    }

    public override string ToString()
    {
        return $"Tenant Id is route argument named '{_argumentName}'";
    }
}

Now, you *could* accurately tell me that this whole strategy pattern nonsense with interfaces and such could be accomplished with mere functions (Func<HttpContext, string?> maybe), and you would be absolutely correct. And I’m going to respond by saying that that is still the “Strategy Pattern” in intent and its role within your code — even though the implementation is different than my C# interface up above. When learning and discussing design patterns, I highly recommend you worry more about the roles and intent of functions, methods, or classes than the actual implementation details.

But also, having the interface + implementing class structure makes it easier for a framework like Wolverine to provide meaningful diagnostics and visualizations of how the code is configured. I actually went down a more functional approach in an earlier framework, and went back to being more OO in the framework guts for reasons of traceability and diagnostics. That’s not necessarily something that I think is generally applicable inside of application code though.

More Complicated: The Marten LINQ Provider

One of the most important points I need to make about design patterns is to use them defensively as a response to a use case in your system rather than picking out design patterns upfront like you’re ordering off of a menu. As a case in point, I’m going to shift to the Marten LINQ provider code. Consider this simplistic usage of a LINQ query:

public static async Task run_linq_query(IQuerySession session)
{
    var targets = await session.Query<Target>()
        // Filter by a numeric value
        .Where(x => x.Number == 5)

        // Filter by an Enum value
        .Where(x => x.Color == Colors.Blue)

        .ToListAsync();
}

Notice the usage of the Where() clauses to merely filter based on both a numeric value and the value of a custom Color enum on the Target document (a fake document type in Marten for exactly this kind of testing). Even in this example, Marten runs into quite a bit of variance as it tries to create SQL to compare a value to the persisted JSONB field within the PostgreSQL database:

• In the case of an integer, Marten can simply compare the JSON field to the actual number
• In the case of an Enum value, Marten will need to compare the JSON field to either the numeric value of the Enum value or to the string name for the Enum value depending on the serialization settings for Marten in the application

In the early days of Marten, there was code that did the variation you see above with simple procedural code something like:

    if (memberType.IsEnum)
    {
        if (serializer.EnumStorage == EnumStorage.AsInteger)
        {
            // create parameter for numeric value of enum
        }
        else
        {
            // create parameter for string name
            // of enum value
        }
    }
    else
    {
        // create parameter for value
    }

In the some of the comments to Oskar’s recent post on the Strategy pattern (maybe on LinkedIn?), I saw someone point out that they thought that moving logic behind strategy pattern interfaces as opposed to simple, inline procedural code made code harder to read and understand. I absolutely understand that point of view, and I’ve run across that before too (and definitely caused myself).

However, that bit of procedural code above? That code started being repeated in a lot of places in the LINQ parsing code. Worse, that nested, branching code was showing up within surrounding code that was already deeply nested and rife with branching logic before you even got into the parameter creation code. Even worse, that repeated procedural code grew in complexity over time as we found more special handling rules for additional types like DateTime or DateTimeOffset.

As a reaction to that exploding complexity, deep code branching, and harmful duplication in our LINQ parsing code, we introduced a couple different instances of the Strategy pattern, including this interface from what will be the V7 release of Marten soon (hopefully):

public interface IComparableMember
{
    /// <summary>
    /// For a member inside of a document, create the WHERE clause
    /// for comparing itself to the supplied value "constant" using
    /// the supplied operator "op"
    /// </summary>
    /// <param name="op"></param>
    /// <param name="constant"></param>
    /// <returns></returns>
    ISqlFragment CreateComparison(string op, ConstantExpression constant);
}

And of course, there are different implementations of that interface for string members, numeric members, and even separate implementations for Enum values stored as integers in the JSON or stored as strings within the JSON. At runtime, when the LINQ parser sees an expression like Where(x => x.SomeProperty == Value), it works by:

1. Finding the known, memoized IComparableMember for the SomeProperty member
2. Calls the IComparableMember.CreateComparison("==", Value) to translate the LINQ expression into a SQL fragment

In the case of the Marten LINQ parsing, introducing the “Strategy” pattern usage did a lot of good to simplify the internal code by removing deeply nested branching logic and by allowing us to more easily introduce support for all new .NET types within the LINQ support by hiding the variation behind abstracted strategies for different .NET types or different .NET methods (string.StartsWith() / string.EndsWith() for example). Using the Strategy pattern also allowed us to remove quite a bit of duplicated logic in the Marten code.

The main takeaways from this more complicated sample:

• The Strategy pattern can sometimes improve the maintainability of your code by reducing the need for branching logic within your code. Deeply nested if/then constructs in code are a veritable breeding ground for software bugs. Slimming that down and avoiding “Arrowhead code” can be a big advantage of the Strategy pattern
• In some scenarios like the Marten LINQ processor, the Strategy pattern is a way to write much more DRY code that also made the code easier to maintain and extend over time. More. on this below.

A Quick Side Note about the Don’t Repeat Yourself Principle

Speaking of backlashes, many developers have a bad taste in their mouthes over the Don’t Repeat Yourself principle (DRY) — or differently stated by the old XP community as “once, and only once.” I’ve even seen experienced developers scream that “DRY is not important!” or go so far as to say that trying to write DRY code is a one way street to unnecessary complexity by introducing more and more abstractions in an attempt to reuse code.

I guess I’m going to end with the intellectual dodge that principles like DRY are really just heuristics that may or might not help you think through what a good structure would be for the functionality you’re coding. They are certainly not black and white rules. In some cases, trying to be DRY will make your code more complex than it might be with a little bit more duplication of some simple code. In the case of the Marten LINQ provider however, I absolutely believe that applying a little bit of DRY with our usage of the Strategy pattern made that code significantly more robust, maintainable, and even simpler in many cases.

Sorry there’s no easy set of rules you can always follow to arrive at good code, but if there actually was, then AI is gonna eat all our lunches anyway.

JasperFx Software has several decades worth of experience with Test Driven Development, developer focused testing, and test automation in general. We’re more than happy to engage with potential clients who are interested in improving their outcomes with TDD or automated testing!

Crap I feel old having typed out that previous sentence.

I’m going through an interesting exercise right now helping a JasperFx client learn how to apply Test Driven Development and developer testing from scratch. The developer in question is very inquisitive and trying hard to understand how best to apply testing and even a little TDD, and that’s keeping me on my toes. Since I’m getting to see things fresh from his point of view, I’m trying to keep notes on what we’ve been discussing, my thoughts on those questions, and the suggestions I’ve been making as we go.

The first things I should have stressed was that the purpose of your automated test suite is to:

1. Help you know when it’s safe to ship code — not “your code is perfect” but “your code is most likely ready to ship.” That last distinction matters. It’s not always economically viable to have perfect 100% coverage of your code, but you can hopefully do enough testing to minimize the risk of defects getting past your test coverage.
2. Provide an effective feedback loop that helps you to modify code. And by “effective,” I mean that it’s fast enough that it doesn’t slow you down, tells you useful things about the state of your code, and it’s stable or reliable enough to be trusted.

Now, switching to Test Driven Development (TDD) itself, I try to stress that TDD is primarily a low level design technique and an important feedback loop for coding. While I’m not too concerned about whether or not the test is written first before the actual code in all cases, I do believe you should consider how you’ll test your code upfront as an input to how the code is going to be written in the first place.

Think about Individual Responsibilities

What I absolutely did tell my client was to try to approach any bigger development task by first trying to pick out the individual tasks or responsibilities within the larger user story. In the first case we were retrofitting tests to, it was a pretty typical web api endpoint that:

• Tried to locate some related entities in the database based on the request
• Validated whether the requested action was valid based on the existence and state of the entities
• On the happy path, make a change to the entity state
• Persist the changes to the underlying database

In the case above, we started by focusing on that validation logic by isolating it into its own little function where we could easily “push” in inputs and do simple assertions against the expected state. Together, we built little unit tests that exercised all the unique pathways in the validation including the “happy path”.

Even this little getting started exercise potentially leads to several other topics:

• The advantage of using pure functions for testable code whenever possible
• Purposely designing for testability (as I wrote about way back in 2008!)
• In our case, I had us break the code apart so we could start in a “bottom up” approach where we coded and tested individual tasks before assembling everything together, versus a top down approach where you try to code the governing workflow of a user story first in order to help define the new API calls for the lower level tasks to build after. I did stress that the bottom up or top down approach should be chosen on a case by case basis.

When we were happy with those first unit tests, we moved on to integration tests that tested from the HTTP layer all the way through the database. Since we had dealt with the different permutations of validation earlier in unit tests, I had us just write two tests, one for the happy path that should have made changes in the database and another “sad path” test where validation problems should have been detected, an HTTP status code of 400 was returned denoting a bad request, and no database changes were made. These two relatively small tests led to a wide range of further discussions:

• Whither unit or integration testing? That’s a small book all by itself, or at least a long blog post like Jeremy’s Only Rule of Testing.
• I did stress that we weren’t even going to try to test every permutation of the validation logic within the integration test harnesses. I tried to say that we were trying to create just enough tests that worked through the execution pathways of that web api method that we could feel confident to ship that code if all the tests were passing
• Watch how much time you’re needing to spend using debugging tools. If you or your team is finding yourself needing to frequently use debuggers to diagnose test failures or defects, that’s often a sign that you should be writing more granular unit tests for your code
• Again with the theme that it’s actually inefficient to be using your debugger too much, I stressed the importance of trying to push through smaller unit tests on coding tasks before you even try to run end to end tests. That’s all about trying to reduce the number of variables or surface area in your code that could be causing integration test failures
• And to not let the debugging topic go quite yet, we did have to jump into a debugger to fix a failing integration test. We just happened to be using the Alba (one of the JasperFx OSS libraries!) library to help us test our web api. One of the huge advantages of this approach is that our web application is running in the same process as the test harness, so it’s very quick to jump right into the debugger by merely re-running the failing test. I can’t stress enough how valuable this is for faster feedback cycles when it inevitably comes time to debug through breaking code as opposed to trying to troubleshoot failing end to end tests running through user interfaces in separate processes (i.e. Selenium based testing).
• Should unit tests and integration tests against the same code be in the same file or even in the same project? My take was just to pay attention to his feedback cycle. If he felt like his test suite ran “fast enough” — and this is purely subjective — keep it simple and put everything together. If the integration tests became uncomfortably slow, then it might be valuable to separate the two poles of tests into the “fast” and “slow” test suites
• Even in this one test, we had to set up expected inputs through the actual database to run end to end. In our case, the data is all identified through globally unique identifiers, so we could add all new data inputs without worrying about needing to teardown or rebuild system data before the test executed. We just barely started a discussion about my recommendations for test data setup.

As an aside, JasperFx Software strongly feels that overusing Selenium, Playwright, or Cypress.io to primarily automate testing through browser manipulation is potentially very inefficient and ineffective compared to more balanced approaches that rely on smaller and faster, intermediate level integration tests like the Alba-based integration testing my client and I were doing above.

“Quick Twitch” Working Style

In the end, you want to be quick enough with your testing and coding mechanics that your progress is only limited by how fast you can think. Both my client and I use JetBrains Rider as our primary IDE, so I recommended:

• Get familiar with the keyboard shortcuts to run test, re-run the last test, or re-run the last test in the debugger so that he could mechanically execute the exact test he’s working on faster without fumbling around with a mouse. This is all about just being able to work as fast as you can think through problems. Other people will choose to use continuous test runners that automatically re-run your tests when file changes are detected. The point either way is just to reduce your mechanical steps and tighten up the feedback loop. Not everything is a hugely deep philosophical subject:-)
• Invest a little time in micro-code generation tooling like Rider’s Live Template feature to help build repetitive code structures around unit tests. Again, the point of this is just to be able to work at the “speed of thought” and not burn up any gray cells dealing with mundane, repetitive code or mouse clicking