DEV Community: Jerrett Davis

Announcing TinyBDD: Fluent, Executable Scenarios for .NET

Jerrett Davis — Sat, 27 Dec 2025 19:29:16 +0000

This article was originally published on my blog.

Announcing TinyBDD: Fluent, Executable Scenarios for .NET

What if the shortest path from "we need this" to "it works in prod" was just a single fluent line of code?

TinyBDD is my attempt to make that path real. It's a lightweight .NET library that lets you write tests in a fluent, Gherkin-ish style—tests that read like acceptance criteria but execute like unit tests. The goal is not ceremony, but clarity: a shared, human-parsable DSL that can span from domain rules to browser automation without losing intent.

This post is the practical follow-up to my earlier essay on BDD. There, I dug into the why. Here, we'll focus on the how: how to go from acceptance criteria to running tests in minutes, how to use Given/When/Then to model even the smallest units, how to orchestrate full end-to-end flows with Playwright, and how writing this way naturally nudges your architecture toward SOLID and composable design.

From acceptance criteria to running tests in minutes

Every team has seen a story like this written in Jira or Confluence:


Scenario: Gold member gets free shipping
Given the customer is a "gold" member
And they have a cart totaling $12.00
When they checkout with standard shipping
Then the shipping cost is $0.00
And the order total is $12.00

With TinyBDD, you don't need separate .feature files unless you want them. You can capture that same intent directly in your test framework, keeping the semantics without the tooling overhead:

await Given("a gold customer with a $12 cart", () => new Cart(Customer.Gold(), 12.00m))
     .When("they choose standard shipping", cart => cart.Checkout(Shipping.Standard))
     .Then("shipping is free", order => order.ShippingTotal == 0.00m)             // Pass/Fail with booleans
     .And("order total is $12.00", order => Expect.For(order.Total).ToBe(12.00m)) // Or Assertions
     .AssertPassed();

The keywords map one-to-one with the business story. Each step is explicit and composable, and the whole chain is easy to read—even for someone outside the dev team. Because the language matches what stakeholders already use, the test itself becomes a living contract.

Unit tests that read like behavior

Behavior-driven style isn't just for top-level acceptance tests. It works equally well for small pieces of logic: a pure function, a discount rule, a transformer. By expressing them as Given/When/Then, you get readability—tiny scenarios that explain the intent before diving into implementation detail—and design pressure, because the format gently encourages pure, composable functions.

Example: a simple discount calculation.

csharp await Given("a silver customer with $100 cart", () => (Tier: "silver", Amount: 100m)) .When("discount is applied", x => Discounts.Apply(x.Tier, x.Amount)) .Then("result is $95", result => result == 95m) .AssertPassed();

Even at this scale, the benefits are obvious. You isolate the decision logic, assert outcomes in plain language, and end up with code that composes neatly into bigger flows later.

End-to-end UI tests with Playwright

TinyBDD also works at the other end of the spectrum: full-stack, end-to-end tests. Here, the key is keeping steps thin and expressive while pushing implementation detail into helpers like page objects or service wrappers. That way, the scenario text stays stable even if the UI shifts underneath.

csharp await Given("a new browser and logged-in gold user", async () => { var pw = await PlaywrightFactory.LaunchAsync(); var page = await pw.NewPageAsync(); await AuthSteps.LoginAsGoldAsync(page); return page; }) .When("user adds a $12 item to cart", async page => { await CatalogSteps.AddItemAsync(page, "SKU-123", 12.00m); return page; }) .And("proceeds to checkout with standard shipping", CheckoutSteps.StandardAsync) .Then("shipping is free", async page => { var shipping = await CartSteps.ReadShippingAsync(page); return shipping == 0.00m; }) .And("order total is $12.00", async page => { var total = await CartSteps.ReadTotalAsync(page); return total == 12.00m; }) .AssertPassed();

Scenarios like this are readable enough for a stakeholder to skim, while still giving engineers the control they need under the hood. Stable wording, deterministic helpers, and tagging (smoke, ui, checkout) all contribute to making suites like this maintainable in real CI pipelines.

Patterns that keep this maintainable

The trick to making end-to-end scenarios sustainable is resisting the temptation to let your steps do all the heavy lifting. The step chain should stay thin and intention-revealing, while the real mechanics live in helpers: page objects, domain services, or test utilities. This keeps the scenario text stable even as the implementation evolves. A good rule of thumb is that a non-technical stakeholder should be able to scan the steps and nod along without ever seeing the helper code. Deterministic helpers—free from hidden global state—are key to repeatable results. And once you have a handful of scenarios, you'll want to tag them (smoke, ui, checkout, etc.) so that CI pipelines can run fast slices for quick feedback and broader sweeps when confidence matters most.

Let tests guide your design

When you write tests in a behavior-first style, architectural friction surfaces quickly. A step that requires half a dozen parameters is rarely a coincidence—it usually means your modules are too tightly coupled. Repeating the same tedious setup across multiple scenarios suggests the absence of a proper abstraction. And if you struggle to phrase a step cleanly, the problem may not be the test at all, but the clarity of your domain language.

These moments of friction are signals. Often, the fix is to extract a pure function from a messy edge, create a port or adapter to decouple infrastructure from business rules, or split a workflow into smaller seams that deserve their own scenarios. In other words: the pressure you feel in writing the test is your design telling you what it wants to become.

BDD and the drift toward SOLID and functional design

Consistently writing scenarios has a shaping effect on code. Steps that do one clear thing align with the Single Responsibility Principle. The ability to add new scenarios without editing existing ones echoes the Open/Closed Principle. And abstractions that are narrow, well-defined, and swappable make substituting fakes and stubs trivial, pushing you toward Liskov, ISP, and DIP almost by default.

The same is true for functional composition. Pure functions naturally slide into Given/When/Then flows. Side effects are easiest to reason about when pushed to the edges—fetching in a Given, transforming in a When, and observing in a Then. And when steps are small and named, they read like a pipeline instead of a mess of conditionals. By following the test style, you often find yourself following the design style too.

A practical way to start tomorrow

If this feels overwhelming, don't boil the ocean. Start with one slice of functionality that everyone values and recognizes—maybe a login path or a simple checkout. Write just two or three scenarios, and make sure the wording mirrors how the business describes the flow. Delegate the mechanics to helpers, not the scenario text. Keep your domain logic in pure functions wherever possible so it's trivial to call from a When step. And once you've got a couple of green runs, wire in some tags so you can choose between smoke tests, integration runs, or the full suite depending on your CI needs.

As you go, pay attention to the words. If step text feels clumsy, it probably means your ubiquitous language is clumsy too. Refining that wording in collaboration with stakeholders isn't overhead—it's the work. And when naming friction crops up, it's often a smell that your design needs another seam or abstraction.

Fluent examples you can copy-paste

Unit-level:

csharp await Given("subtotal is $120 and tier is gold", () => (Subtotal: 120m, Tier: "gold")) .When("finalize price", x => Pricing.Finalize(x.Tier, x.Subtotal)) .Then("applies 10% discount", price => price == 108m) .AssertPassed();

API-level:

csharp await Given("a seeded test tenant", TestData.SeedTenantAsync) .When("posting to /invoices", async _ => await Api.PostAsync("/invoices", new { amount = 250 })) .Then("returns 201", r => r.StatusCode == 201) .And("body contains invoice id", r => r.Json.Value<string>("id") is { Length: > 0 }) .AssertPassed();

UI-level:

csharp await Given("a logged-in admin", BrowserSteps.LoginAsAdminAsync) .When("they create a user named Dana", page => AdminUsers.CreateAsync(page, "Dana")) .Then("Dana appears in the grid", page => AdminUsers.ExistsAsync(page, "Dana")) .AssertPassed();

Readable Gherkin-style output

One of the nicest touches in TinyBDD is how your scenarios report themselves when you run the tests. Pair your scenarios with the appropriate base class (TinyBddXunitBase, TinyBddXunitV3Base, TinyBddNUnitBase, or TinyBddMSTestBase), and the test runner will print structured Gherkin output alongside normal results.

That means the Given/When/Then flow you wrote doesn't just execute—it shows up exactly as you'd expect, step by step, with timings and pass/fail indicators. It turns your test logs into living specifications.

For example, here's the output from a mediator scenario:

Feature: Behavioral - Mediator (commands, notifications, streaming, behaviors)
Scenario: Send: command handler runs through behaviors and returns value
Given a mediator with pre/post/whole behaviors and a Ping->Pong handler [OK] 2 ms
When sending Ping(5) [OK] 4 ms
Then result is pong:5 [OK] 2 ms
And behaviors logged pre, whole before/after, and post [OK] 0 ms

Instead of squinting at assertions in code, you see a natural-language story of what happened. That's invaluable when sharing results with stakeholders or debugging failures in CI. And because the feature and scenario titles come from your test class and attributes, the logs stay consistent with the language you use in code reviews, planning, and conversations.

Avoiding common anti-patterns

Every test framework accumulates bad habits if left unchecked, and TinyBDD is no exception. The most obvious trap is clever wording: steps like "When magic happens" don't help anyone and fail to serve as documentation. Instead, the wording should describe an intention that a stakeholder would immediately recognize, such as "When the admin disables the account". Another trap is letting a single step conceal multiple actions or checks. Keep your flow honest: When should drive effects, and Then or And should assert results.

Setup is another danger zone. If your Given steps are littered with manual wiring of objects, it's time for factories or builders to take over. And at the UI layer, brittle selectors quickly make tests flaky; encapsulating them in page objects and using explicit test IDs pays off many times over. Avoiding these pitfalls keeps your suite readable, stable, and genuinely valuable.

The payoff

When scenarios read like the business and execute like the code, something special happens. Your tests stop being just a safety net and start becoming living documentation. They never go stale because they're executable. They provide immediate feedback on drift, so change becomes safer. They subtly nudge your codebase toward SOLID principles and functional seams. And for new developers, they become the best possible onboarding guide: open the suite, read the stories, and understand how the system behaves.

You don't need to retool your world to reach this point. Start with one scenario. Make it pass. Share it with your team. Repeat. In a few sprints, you'll have a suite of stories that stack from units to workflows, and a codebase that's easier to evolve because the behaviors are crystal clear.

Appendix — A quick PR lens

As you review changes, ask yourself: does this PR add or update scenarios that the business would recognize? Do the steps read like natural English, each mapping to a single intent? Are the domain rules isolated in pure functions rather than tangled in infrastructure? Did we create or clarify a port instead of hard-coding dependencies? Can we tag and run this slice of scenarios independently in CI?

If you can answer "yes" to most of those, you're not just writing tests—you're building shared understanding, guiding design, and accelerating delivery. That's the real promise of TinyBDD.

👉 Get TinyBDD on GitHub · NuGet · Docs

JD.Efcpt.Build: Build‑Time EF Core Scaffolding to Keep Database‑First Models in Sync

Jerrett Davis — Mon, 22 Dec 2025 05:43:45 +0000

"Where Did Database First Go?"

If you were using Entity Framework when EF Core first dropped, you probably remember the moment you went looking for database-first support and found... nothing.

EF Core launched as a code-first framework. The Reverse Engineer tooling that EF6 developers relied on (the right-click, point at a database, generate your models workflow) wasn't there. Microsoft's position was essentially "migrations are the future, figure it out." And if your team had an existing database, or a DBA who actually owned the schema, or compliance requirements that meant the database was the source of truth... well, good luck with that.

The community's response was immediate and loud. "Where did database first go?" became a recurring theme in GitHub issues, Stack Overflow questions, and the quiet frustration of developers who just wanted to talk to their database without hand-writing a hundred entity classes.

Eventually, tooling caught up. EF Core Power Tools emerged as the community answer: a Visual Studio extension that brought back the reverse engineering workflow. You could point it at a database or a DACPAC, configure some options, and generate your models. Problem solved, mostly.

But here's the thing about manual processes: they work fine right up until they don't.

The Problem That Keeps Happening

I've spent enough time in codebases with legacy data layers to recognize a pattern. It goes something like this:

A project starts with good intentions. Someone sets up EF Core Power Tools, generates the initial models, commits everything, and documents the process. "When the schema changes, regenerate the models using this tool with these settings." Clear enough.

Then time passes.

The developer who set it up leaves. The documentation gets stale. Someone regenerates with slightly different settings and commits the result. Someone else forgets to regenerate entirely after a schema change. The models drift. The configuration drifts. Nobody's quite sure what the "correct" regeneration process is anymore, so people just... stop doing it consistently.

This isn't a dramatic failure. It's a slow erosion. The kind of problem that doesn't announce itself until you're debugging a production issue and realize the entity class doesn't have a column that's been in the database for six months.

If you've worked in a codebase long enough, you've probably seen some version of this. Maybe you've been the person who discovered the drift. Maybe you've been the person who caused it. (No judgment. We've all been there.)

The frustrating part is that the fix is always the same: regenerate the models, commit the changes, remind everyone to regenerate after schema changes. And then six months later, you're having the same conversation again.

Why Manual Regeneration Fails

Let's be specific about what goes wrong, because understanding the failure modes is the first step toward fixing them.

The ownership problem. Whose job is it to regenerate after a schema change? The person who changed the schema? The person who owns the data layer? The tech lead? Nobody has a clear answer, which means sometimes everyone does it (chaos) and sometimes nobody does it (drift).

The configuration problem. EF Core Power Tools stores settings in JSON files. Namespaces, nullable reference types, navigation property generation, renaming rules. There are dozens of options. If developers regenerate with different configurations, you get inconsistent output. Same database, different generated code.

The tooling problem. Regeneration requires Visual Studio with the extension installed. CI servers don't have Visual Studio. New developers might not have the extension. Remote development setups might not support it. The process that works on one machine doesn't necessarily work on another.

The noise problem. Regeneration often produces massive diffs. Property reordering, whitespace changes, attribute additions. Stuff that doesn't represent actual schema changes but clutters up the commit. Developers learn to distrust regeneration diffs, which makes them reluctant to regenerate, which makes the problem worse.

The timing problem. Even when everyone knows the process, there's no enforcement. You can commit code that references a column the models don't have, and the build might still pass if nothing actually uses that code path yet. The error surfaces later, in a different context, when the connection to the original schema change is long forgotten.

None of these are individually catastrophic. Together, they add up to a process that works in theory but fails in practice.

The Idea

Here's the thought that eventually became this project: if model generation can be invoked from the command line (and it can, via EF Core Power Tools CLI), then model generation can be part of the build.

Not a separate step you remember to run. Not a manual process with unclear ownership. Just part of what happens when you run dotnet build.

The build already knows how to compile your code. It already knows how to restore packages, run analyzers, produce artifacts. Adding "generate EF Core models from the schema" to that list isn't conceptually different from any other build-time code generation.

If the build handles it, the ownership question disappears. The build owns it. If the build handles it with consistent configuration, the drift disappears. Everyone gets the same output. If the build handles it on every machine, the tooling problem disappears. No special extensions required.

This is JD.Efcpt.Build: an MSBuild integration that makes EF Core model generation automatic.

How It Actually Works

The package hooks into your build through MSBuild targets that run before compilation. When you build, it:

Finds your schema source. Either a SQL Server Database Project (.sqlproj) that gets compiled to a DACPAC, or a connection string pointing to a live database.
Computes a fingerprint. A hash of all the inputs: the DACPAC or schema metadata, the configuration file, the renaming rules, any custom templates. This fingerprint represents "the current state of everything that affects generation."
Compares to the previous fingerprint. If they match, nothing changed, and generation is skipped. If they differ, something changed, and generation runs.
Generates models. Using EF Core Power Tools CLI, same as you'd run manually, but automated. Output goes to obj/efcpt/Generated/ with a .g.cs extension.
Adds generated files to compilation. Automatically. You don't edit your project file or manage includes.

The fingerprinting is what makes this practical. You don't want generation running on every build. That would be slow and developers would hate it. The fingerprint check is fast (XxHash64, designed for exactly this kind of content comparison), so incremental builds have essentially zero overhead. Generation only runs when inputs actually change.

Two Ways to Get Your Schema

Different teams manage database schemas differently, so the package supports two modes.

DACPAC Mode is for teams with SQL Server Database Projects. You have a .sqlproj that defines your schema in version-controlled SQL files. The package builds this project to produce a DACPAC, then generates models from that DACPAC.

<PropertyGroup>
  <EfcptSqlProj>..\Database\MyDatabase.sqlproj</EfcptSqlProj>
</PropertyGroup>

This is nice because your schema is code. It lives in source control. Changes go through pull requests. The DACPAC is a build artifact, and models are derived from that artifact deterministically.

Connection String Mode is for teams without database projects. Maybe you apply migrations to a dev database and want to scaffold from that. Maybe you're working against a cloud database. Maybe you just don't want to deal with DACPACs.

<PropertyGroup>
  <EfcptConnectionString>$(DB_CONNECTION_STRING)</EfcptConnectionString>
</PropertyGroup>

The package connects, queries system tables to understand the schema, and generates from that. The fingerprint is computed from the schema metadata, so incremental builds still work. If the schema hasn't changed, generation is skipped.

Both modes use the same configuration files and produce the same kind of output. They just differ in where the schema comes from.

Setting It Up

The minimum setup is almost trivial:

<ItemGroup>
  <PackageReference Include="JD.Efcpt.Build" Version="1.0.0" />
</ItemGroup>

If you have a .sqlproj in your solution and an efcpt-config.json in your project directory, that's it. Run dotnet build and models appear.

For more control, you add configuration. The efcpt-config.json controls generation behavior:

{
  "names": {
    "root-namespace": "MyApp.Data",
    "dbcontext-name": "ApplicationDbContext"
  },
  "code-generation": {
    "use-nullable-reference-types": true,
    "enable-on-configuring": false
  }
}

The enable-on-configuring: false means your DbContext won't have a hardcoded connection string. You configure that in your DI container, where it belongs.

If your database uses naming conventions that don't map cleanly to C#, you add renaming rules:

[
  {
    "SchemaName": "dbo",
    "Tables": [
      {
        "Name": "tbl_Users",
        "NewName": "User",
        "Columns": [
          { "Name": "user_id", "NewName": "Id" }
        ]
      }
    ]
  }
]

Now tbl_Users.user_id becomes User.Id. The database can keep its conventions, your C# code can have its conventions, and the mapping is explicit and version-controlled.

What About Custom Code?

A reasonable concern: "I have computed properties and validation methods on my entities. Won't regeneration overwrite those?"

This is what partial classes are for.

The generated entity is one half:

// obj/efcpt/Generated/User.g.cs
public partial class User
{
    public int Id { get; set; }
    public string Email { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

Your custom logic is the other half:

// Models/User.cs
public partial class User
{
    public string FullName => $"{FirstName} {LastName}";

    public bool HasValidEmail => Email?.Contains("@") ?? false;
}

Both compile into a single class. The generated half gets regenerated every build. Your custom half stays exactly as you wrote it.

This separation is actually cleaner than mixing generated and custom code in the same file. You know at a glance what's generated (.g.cs in obj/) and what's yours (everything else).

CI/CD Without Special Steps

One of the pain points I mentioned earlier was CI/CD. Manual regeneration doesn't work in automated pipelines. You're stuck either committing generated code (merge conflicts) or maintaining custom regeneration scripts (fragile).

With the build handling generation, CI just works:

steps:
  - uses: actions/checkout@v4

  - name: Setup .NET
    uses: actions/setup-dotnet@v4
    with:
      dotnet-version: '10.0.x'

  - name: Build
    run: dotnet build --configuration Release
    env:
      DB_CONNECTION_STRING: ${{ secrets.DB_CONNECTION_STRING }}

No special steps for EF Core generation. The build handles it. On .NET 10+, the package uses dotnet dnx to execute the tool directly from the package feed without requiring installation. On older versions, it uses tool manifests or global tools.

Pull requests that include schema changes automatically include the corresponding model changes, because both happen during the build. Schema and code are validated together.

When Things Go Wrong

Things will go wrong. Here's how you figure out what happened.

Enable verbose logging:

<PropertyGroup>
  <EfcptLogVerbosity>detailed</EfcptLogVerbosity>
</PropertyGroup>

Build output now includes exactly what's happening: which inputs were found, what fingerprint was computed, whether generation ran or was skipped.

Check the resolved inputs:

After a build, look at obj/efcpt/resolved-inputs.json. This shows exactly what the package found for each input. If something's wrong, you'll see it here.

Inspect the fingerprint:

The fingerprint is stored at obj/efcpt/fingerprint.txt. If generation is running unexpectedly (or not running when it should), the fingerprint tells you whether inputs changed from the package's perspective.

Who This Is For

I want to be honest about fit.

This is probably for you if:

You're doing database-first development and you've experienced the regeneration coordination problem. The "did someone regenerate?" question has come up, and the answer wasn't always clear.

Your schema changes regularly. If you're shipping schema changes weekly, manual regeneration becomes friction.

You want builds that work identically everywhere. Local machines, CI servers, new developer laptops. Everyone should get the same generated code from the same inputs.

This probably isn't for you if:

Your schema is essentially static. If schema changes are rare, manual regeneration isn't that painful.

You're using code-first migrations. If migrations are your source of truth, you're solving a different problem.

You're not using EF Core Power Tools already. This package automates EF Core Power Tools; if you're using a different generation approach, this doesn't apply.

The Groan, Addressed

"Where did database first go?"

It's been years since EF Core launched without reverse engineering, and the tooling has caught up. EF Core Power Tools exists. The CLI exists. The capability is there.

But capability isn't the same as workflow. Having the tools isn't the same as having a process that works reliably across a team, across time, across environments.

JD.Efcpt.Build is an attempt to close that gap. To take the capability that exists and make it automatic. To make the build the owner of model generation, so humans don't have to remember to do it.

Your database schema is the source of truth. This package just makes sure your code reflects that truth, every time you build, without manual intervention.

One less thing to coordinate. One less thing to forget. One less thing to go wrong in production because a manual step got skipped.

That's the pitch. Give it a try if it fits your situation.

JD.Efcpt.Build is open source and available on NuGet.

You Don't Hate Abstractions

Jerrett Davis — Mon, 08 Dec 2025 01:08:42 +0000

It’s an hour until you’re free for the weekend, and you’re trying to knock out one
last ticket before you escape into whatever assuredly action-packed plans await you.
You spot a seemingly harmless task: "Add Middle Initial to User Name Display."

You chuckle. Easy. A palate cleanser. A victory lap.

You assign the ticket, flip it from New to Active, and let your IDE warm up

while you drift into a pleasant daydream about not being here.

But then the search results begin to appear.

Slowly. Line by line.

And your reverie begins to rot.

IUserNameStrategy, UserNameContext, UserNameDisplayStrategyFactory,

StandardUserNameDisplayStrategy, FormalUserNameDisplayStrategy,

InformalUserNameDisplayStrategy, UserNameDisplayModule, …

Incredulous, your chuckle hardens into a throat-scraping noise somewhere
between a laugh and a cry.

"What in the Gang-of-Fuck is happening here," you think, feeling your pulse tick up.
"Either someone read Refactoring.Guru like it was scripture and decided to
baptize the codebase in every pattern they learned, or a grizzled enterprise
veteran escaped some Netflix-adjacent monolith and is trying to upskill in
TypeScript. Because surely no sane developer would build this much redirection
for such a trivial feature… right?"

That tiny, spiraling task is a perfect microcosm of a continuous debate across engineering circles: when does abstraction help, and when does it become a hindrance?

I recently stumbled across the humorous article You're Not Building Netflix: Stop Coding Like You Are by Adam — The Developer. But though it resonates in many ways, its broader critique is ultimately misdirected.

Adam opens with a more complete version of the code mocked in my prologue, and uses the verbosity and obscurity of that abstraction pile as the springboard for a rebuke of using enterprise patterns pretty much across the board. While the author does allow for some abstractions, they're limited in application and scope.

The problem isn’t that the complaint is wrong. It’s that it points the finger at the wrong culprit, just about literally missing the forest for the trees.

Abstractions are fundamental and essential. They are the elementary particles of software, the quarks and leptons that bind into the subatomic structures that become the atoms our earliest techno-wizards fused into molecules. Today we combine those same basic elements into the compounds and contraptions made for use by millions. Without abstractions, we are left helpless in the ever-increasing parallel streams of pulsating electrical currents, rushing through specialized, intricately forged rocks that artisan wizards once trapped lightning inside and somehow convinced to think.

But even with all that power at our disposal, the way we use these building blocks matters. Chemistry offers a fitting parallel. Food chemists, for example, have spent decades learning how to repurpose industrial byproducts into stabilizers, textures, preservatives, and anything else that can be quietly slipped into a recipe. Much of this work is impressive and innovative, but some of it is little more than creative waste disposal disguised as convenience: a brilliant hack in the short term and a lingering problem in the long one.

Developers can fall into the same pattern. We learn a new technique or pattern or clever trick and then spend the next year pouring it into every beaker we can find. We are not always discovering better processes. Sometimes we are just repackaging the same product and calling it progress. When that happens, we are not solving problems. We are manufacturing new ones that future maintainers will curse our names over.

A developer must be architect, engineer, mechanic, and driver all at once. It is fine to know how to fix a specific issue, but once that problem is solved, that knowledge should become a building block for solving the next one. If we keep returning to maintain the same solution day after day, then what we built was never a solution at all. It was a slow-burning maintenance burden that we misfiled as "done."

Abstractions exist to reduce complexity, not to multiply it. Their purpose is to lighten the cognitive load, to lift the details off your desk so you can see the shape of the problem in front of you. Terse, repetitive, wire-on-the-floor code that looks like it tumbled out of a flickering green CRT from 1999 may impress the authors who have stared at machine code long enough to discern hair color from a data stream, but it does not serve the broader team or the system that outlives them. Abstractions only do their job when they are aligned with the actual problem being solved, and that brings us to the part many developers skip entirely: modeling your software after the problem you are solving.

Seeing the Problem Before Solving It

When you build a system, any system, even a disposable script, the first responsibility is understanding why it exists. What problem does it address. Has that problem been solved before. If so, what makes the existing solution insufficient for you now. Understanding that difference is the foundation that everything else must sit on.

I learned this the hard way as a homeowner. My house is old enough to have grounded me if I talked back to it as a teenager. A couple of years ago we went through a near-total remodel. We did some work before and shortly after our daughter was born, but within a year new problems started surfacing. We brought in a structural engineer. The slab foundation was heaving. After some exploration we discovered the culprit: the original cast iron sewage line had split along both the top and bottom, creating pressure changes and settling issues throughout the house.

The fix was not small. We pulled up every inch of flooring. Replaced baseboards. Repaired drywall. Fixed the broken line. Repainted entire sections. Redid trim. Installed piers. Pumped in foundation foam. Cashed in favors. Lost many weekends. And yet, even with all that, it still cost far less than buying an equivalent house in the current market at the current rates.

The lesson is simple. Things are rarely a total loss. Even when a structure looks hopeless, even when someone has effectively set fire to best practices, even when regulations or markets or technologies have shifted dramatically, there are almost always assets worth salvaging inside the wreckage. You should not bulldoze unless you know you have truly exhausted the alternatives.

Before throwing away any system and starting another from scratch, assess what you already have. Understand what is broken, what is sound, and what simply needs reinforcement. Software, like houses, tends to rot in specific places for specific reasons. Understanding those reasons is what separates renovation from reinvention.

The Nightstand Problem

The same principle applies at a smaller scale. You may already own a perfectly functional house with perfectly functional furniture, yet still want a nightstand you do not currently possess. Your choices are straightforward. You can hope someone has decided to let go of one that happens to meet your criteria. That is the open source gamble. You can buy one, constrained only by budget and whatever definition of quality the manufacturer is committed to that week. Or you can build one yourself, limited only by your skills, imagination, and tolerance for sawdust.

If your goal is personal satisfaction or experimentation, then by all means build the nightstand. But if your goal is to sell or support a product that helps make money, you are no longer just hobby-carpenting. You are operating in the domain of enterprise software.

And when you are building enterprise software, you must view the system from the top down while designing from the bottom up. From the top down, you think about every consumer of your system. In academic terms these are actors. Any system intended to be used, whether by humans or machines, is defined by the interactions between its actors and its responsibilities. Even an autonomous system is both an actor and the architected environment it operates within.

This perspective matters because it forces your abstractions to model the real world rather than some internal taxonomy of clever names. Good abstractions emerge from an understanding of the domain. Bad abstractions emerge from an understanding of a design pattern book.

And if you want maintainability, clarity, and longevity, you always want the first.

Building from Both Directions

Designing software means working from two directions at once. On one hand, you must understand the behavior your system must exhibit. On the other hand, you must understand the shape of the world it lives in. Systems are not invented whole cloth; they crystallize out of the interactions between intentions and constraints. If you ignore either direction, you end up with something brittle, confused, overbuilt, or perpetually unfinished.

There is nothing sacred about any particular architectural style. Pick Domain-Driven, Clean, Vertical Slice, Hexagonal, Layered, or something entirely different. The choice matters far less than your consistency and your commitment to encapsulating concerns properly. Different problems require different arrangements of the same conceptual ingredients. From high altitude, two domains may look identical. Once you descend toward the details, you often discover that one is a bird and the other is an airplane. The trick is knowing when to zoom out and when to zoom in.

Plenty of developers jump immediately into code, but the outside of the system is always the real beginning. What is it supposed to do. Who uses it. Who does it talk to. Who builds it. Who runs it. Who deploys it. Who monitors it. How do you prove it works. These questions define the problem space, and the problem space determines the boundaries and responsibilities your abstractions must reflect.

Even something as small as a script must obey this reality.

Consider a simple provisioning script. First it reads a certificate from the local filesystem so it can authenticate with a remote host. Next it opens an SFTP connection to a distribution server and retrieves a zip file. Then it extracts the archive to a temporary directory provided by the operating system. Finally it executes whatever installers or configuration commands the archive contains.

On the surface this is straightforward, yet every step is shaped by the environment in which it operates. Tools differ between platforms. Available executables change. File paths and separators vary. Temporary directory locations vary. Even the existence or reliability of SFTP clients varies. None of this means we must implement every possible alternative upfront, but it does mean we should acknowledge the existence of alternatives and avoid designing ourselves into a corner where adding support later requires rewriting the entire script.

This principle scales upward. You may choose to place your application data inside a database, but scattering SQL statements across your codebase is an anti-pattern in nearly any architecture not explicitly about database engines or ORM internals. Unless you are writing an RDBMS, data access is rarely the star of the show. The real substance lives in the application logic that interprets, transforms, regulates, or composes that data. Mixing data access concerns directly into that logic creates friction. Separating them reduces friction, which improves maintainability, which improves confidence, which improves speed.

The guiding question is always the same: does this choice help my system model the problem more clearly, or does it merely model my current implementation?
If it is the former, great. If it is the latter, you are accumulating technical debt even if the code looks clean.

Abstractions aligned with the domain allow your system to grow gracefully. But abstractions aligned with your tooling force your system to grow awkwardly and inconsistently.

This is the difference between designing from both directions and designing from just one.

Behavior as the Backbone of Architecture

At some point in every software project, the discussion inevitably turns to architecture. Engineers debate whether they should adopt Domain-Driven Design or Clean Architecture, whether their services ought to be hexagonal, layered, vertical-sliced, modular, or some other fashionable geometric configuration, and whether interfaces belong everywhere or nowhere at all. These conversations are interesting, even entertaining, but they often drift into abstraction for abstraction’s sake. The problem is rarely the patterns themselves; rather, it is that these debates frequently occur in a vacuum, disconnected from the actual behaviors the system must exhibit. Humans love patterns, but software only cares about whether it does the right thing.

The most reliable way to design a system, therefore, is to begin with its behavior. A system exists to do something, and if we do not articulate that something clearly, everything downstream becomes guesswork and improvisation. This is precisely where behavior-driven development demonstrates its value. I explore this more deeply in BDD: Make the Business Write Your Tests, but in short, BDD forces us to express the responsibilities of the system in language that is precise, verifiable, and shared by both technical and nontechnical stakeholders. A behavior becomes a specification, a test, a boundary, and a contract all at once.

From an architectural perspective, this shift in thinking is transformative. When we model the largest and most meaningful behaviors first and place an abstraction around them, we create an outer shell that defines the system at a conceptual level. From there, we move inward, breaking behaviors down iteratively into smaller and more specific responsibilities. Each division suggests a natural abstraction, but these abstractions are not arbitrary. They emerge directly from the behavior they represent. They are shaped not by the developer’s preferred patterns but by the needs of the domain itself. This recursive approach ensures that abstractions mirror intent rather than implementation details.

Importantly, this recursion is not fractal. We are not attempting to subdivide reality endlessly. Rather, we refine behaviors only until they are sufficiently well understood to be implemented cleanly. Much as one does not explain quantum chromodynamics to teach someone how to scramble an egg, we do not decompose software beyond what clarity and accuracy require. And while many languages encourage the use of interfaces as the primary mechanism for abstraction, the interface is not the abstraction itself. It is merely a convenient way to enforce a contract. The real abstraction is the conceptual boundary it represents. Whether that boundary is expressed as an interface, a type, a configuration object, or a module is irrelevant as long as the contract is clear and consistent.

This is why starting with abstractions like an IHost that orchestrates an IApplication works so well. These constructs mirror the system’s highest-level behaviors. Once defined, they allow us to drill inward, step by step, carving out responsibilities until the domain takes shape as a set of interlocking, behavior-aligned components. When abstractions are created this way, they tend to be stable. They align with the problem domain rather than the transient needs of a particular implementation, and therefore they seldom need to change unless the underlying behavior changes.

Frequent modification of an abstraction is a warning sign. A well-formed abstraction typically changes only under three conditions: the business behavior has evolved, an overlooked edge case has surfaced, or the original abstraction contained a conceptual flaw. Outside of those circumstances, the need to repeatedly modify an abstraction usually indicates that its boundaries were drawn incorrectly. When adjusting one behavior forces changes across multiple components, the issue is rarely "too many" or "too few" abstractions in an abstract sense. Instead, it is a failure of alignment. The abstraction does not adequately contain the concerns it is supposed to model, and complexity is leaking out of its container and into the rest of the codebase.

Modern tooling makes this problem even more evident. With the availability of source generators, analyzers, expressive type systems, code scaffolding, and dynamic configuration pipelines, there is increasingly little justification for sprawling boilerplate or repetitive structural code. Boilerplate is not a mark of engineering rigor. It is simply untested and uninteresting glue repeated dozens of times because someone did not take steps to automate it. Good abstractions, by contrast, elevate meaning. They allow the domain to be expressed directly without forcing the developer to wade through noise.

This leads naturally to what I consider the ideal state of modern development: a system that is entirely automated from the moment code touches a repository until the moment it reaches a production-like environment. Compilation, testing, packaging, deployment, orchestration, and infrastructure provisioning should not require human involvement. The only manual step should be expressing intent in the form of new or updated behaviors. Every function that exists within the system should originate as a behavior-driven specification capable of running the entire application inside a controlled test environment, complete with containerized dependencies and UI automation tools such as Playwright. Those same tests should also be able to stub dependencies so the scenarios can run in isolation. When the system itself is treated as the first unit under test, orchestration becomes a priority rather than an afterthought.

Achieving this level of automation depends on stability, and that stability depends on disciplined abstraction. Any element that may vary across environments, including configuration values, credentials, infrastructure, connection details, and policies, must be isolated behind settings and contracts that the application can consume without knowing anything about the environment it runs in. Once this encapsulation is in place, behavior-driven specifications can operate confidently, verifying the correctness of the system from the outside in even while its internal components remain free to evolve.

Finally, it is worth stating explicitly that hand-writing repetitive boilerplate code in a CRUD-heavy application, such as repositories, controllers, mappers, DTOs, validators, or entire edge-to-edge layers, is not admirable craftsmanship. It is busywork. If you have twenty entities with identical structural behavior and you are manually writing twenty sets of nearly identical files, the issue is not insufficient discipline. It is insufficient automation. Whether through source generators, templates, reflection-based pipelines, or dynamic modules, these problems can and should be solved generically. Engineers should focus their manual effort on the places where meaning lives: the domain, the behavior, and the boundaries.

Good abstractions do not eliminate complexity; they contain it. Bad abstractions distribute it. And behavior-driven, problem-first design is how we tell the difference.

From Story to Spec: Describing Behavior First

To make this concrete, return to our original "Add Middle Initial to User Name Display" ticket. Most teams would handle this with a couple of unit tests directly against whatever UserNameService or UserNameFormatter happens to exist. The tests would exercise a particular class, call a particular method, and assert on a particular string. That can work, but it starts at the implementation, not at the behavior.

If instead we begin with behavior, the specification sounds more like this:

When a user has a middle name, show the middle initial between the first and last name.
When a user does not have a middle name, omit the gap entirely.
When a display style changes (for example, "formal" versus "informal"), the rules about how the middle initial appears should still hold.

That is the contract. It does not mention classes, factories, or strategies. It talks about what the system must do from the outside.

With something like my project TinyBDD, that kind of behavior becomes executable in a fairly direct way. Using the xUnit adapter, a scenario might look like this:

using TinyBDD.Xunit;
using Xunit;

[Feature("User name display")]
public class UserNameDisplayScenarios : TinyBddXunitBase
{
    [Scenario("Standard display includes middle initial when present")]
    [Fact]
    public async Task MiddleInitialIsRenderedWhenPresent()
    {
        await Given("a user with first, middle, and last name", () =>
                new UserName("Ada", "M", "Lovelace"))
            .When("formatting the user name for standard display", user =>
                UserNameDisplay.Standard.Format(user))
            .Then("the result places the middle initial between first and last", formatted =>
                formatted == "Ada M. Lovelace")
            .AssertPassed();
    }

    [Scenario("Standard display omits missing middle initial")]
    [Fact]
    public async Task NoMiddleInitialWhenMissing()
    {
        await Given("a user with only first and last name", () =>
                new UserName("Ada", null, "Lovelace"))
            .When("formatting the user name for standard display", user =>
                UserNameDisplay.Standard.Format(user))
            .Then("no dangling spaces or periods appear", formatted =>
                formatted == "Ada Lovelace")
            .AssertPassed();
    }
}

In these scenarios, the behavior is the first-class citizen. The test does not care whether you use a UserNameDisplayStrategyFactory, a dependency-injected IUserNameFormatter, or a static helper hidden in a dusty corner of your codebase. It cares that given a user, when you format their name, you get the right string.

The abstractions are already visible in the code, but only as a side effect of expressing behavior:

UserName represents the domain concept of a person’s name, not a UI or persistence model.
UserNameDisplay.Standard represents a particular display style that the business cares about.
The behavior is encoded in the transition from UserName to the formatted string, not in a particular class hierarchy.

Notice what is not present: we do not have separate strategies for every permutation of name structure, locale, and display preference. We have a single coherent abstraction around "displaying a user name in the standard way," and the test drives the rules we actually need.

Letting Abstractions Fall Out of the Domain

Once you have a behavior-focused spec, the abstractions almost draw themselves. One reasonable implementation might look like this:

public sealed record UserName(
    string First,
    string? Middle,
    string Last);

public interface IUserNameDisplay
{
    string Format(UserName name);
}

public sealed class StandardUserNameDisplay : IUserNameDisplay
{
    public string Format(UserName name)
    {
        if (!string.IsNullOrWhiteSpace(name.Middle))
        {
            return $"{name.First} {name.Middle[0]}. {name.Last}";
        }

        return $"{name.First} {name.Last}";
    }
}

public static class UserNameDisplay
{
    public static readonly IUserNameDisplay Standard = new StandardUserNameDisplay();
}

This is not an argument that every trivial formatting problem deserves an interface and a concrete class. You could inline this logic in a static helper and your tests above would still pass. The point is that the abstraction here is small, meaningful, and directly aligned with the behavior we care about. If later the domain grows to include multiple display styles, cultures, or localization concerns, there is already a clear seam to extend. You can introduce additional IUserNameDisplay implementations where and when they are genuinely needed, not because a pattern catalog declared that every noun deserves a factory.

If, however, you discover that adding a new behavior requires touching half the classes in the system, that is a sign you have modeled implementation variants rather than domain concepts. The behavior spec remains constant; the code churn reveals where your abstractions are misaligned.

Scaling the Same Idea Up to the System Level

So far this is all very local. A name goes in, a formatted string comes out. Real systems have much more interesting behaviors: accepting traffic, orchestrating workflows, integrating with external services, healing from transient failures, deploying safely, and so on.

The same discipline still applies. You can treat the application itself as the unit under test and express its behavior with the same style of specification. A high-level scenario might read something like this:

Given a configured application host and its dependencies
When the host starts
Then the public API responds to a health probe
And all critical services report healthy
And any failing dependency is surfaced clearly rather than silently ignored

As an executable TinyBDD scenario, that might look like:

using TinyBDD.Xunit;
using Xunit;

[Feature("Application startup and health")]
public class ApplicationHealthScenarios : TinyBddXunitBase
{
    [Scenario("Host starts and exposes a healthy API surface")]
    [Fact]
    public async Task HostStartsAndReportsHealthy()
    {
        await Given("a test host with default configuration", () =>
                TestApplicationHost.CreateDefault())
            .When("the host is started", async host =>
            {
                await host.StartAsync();
                return host;
            })
            .Then("the health endpoint returns OK", async host =>
                await AssertHealthEndpointOk(host, "/health"))
            .And("all critical health checks pass", async host =>
                await AssertCriticalChecksPass(host))
            .AssertPassed();
    }

    private static Task AssertHealthEndpointOk(TestApplicationHost host, string path)
    {
        // This could exercise a real HTTP endpoint against a TestServer or containerized instance.
        // The assertion lives here, but the behavior is defined in the scenario above.
        throw new NotImplementedException();
    }

    private static Task AssertCriticalChecksPass(TestApplicationHost host)
    {
        // Could query IHealthCheckPublisher, metrics, logs, or an in-memory probe endpoint.
        throw new NotImplementedException();
    }
}

The implementation details behind TestApplicationHost are intentionally omitted here, because they are not the main point. What matters is that at the boundary, we are still describing behavior: the host starts, the API responds, health checks pass. Internally, TestApplicationHost can wrap an IHost, use Testcontainers, spin up a WebApplicationFactory, or compose a full stack in Docker. The abstraction exists to let the behavior remain stable while infrastructure details evolve.

This is the same pattern you used on the small scale with UserNameDisplay, only now it operates at the level of the entire application. The outermost abstraction represents the system as it is experienced from the outside. Everything underneath exists to satisfy that experience.

Declarative Core, Automated Edge

Once specifications like these exist, they become the backbone of your automation. The natural end state is a development flow where:

A new behavior is introduced as a TinyBDD scenario.
That scenario boots the application in a realistic but controlled environment.
The rest of the stack compiles, configures, and deploys itself into a test harness without manual intervention.
The same scenarios run in local, CI, and pre-production environments, with only configuration differing between them.

The actual application code can then remain highly declarative. Controllers or handlers describe what should happen when a request arrives. Domain services express rules and policies in terms of value objects and aggregates. Infrastructure concerns hide behind interfaces and adapters. Source generators or templates can remove boilerplate around repetitive CRUD or mapping concerns. The tests remain focused on behavior: does the system do what we said it would do.

Abstractions in this world are not ornamental. They are the scaffolding that holds the behavior in place while the infrastructure and implementation details shift around it. As long as the specifications stay clear and the boundaries remain aligned with the domain, you can move quickly without losing correctness. And if you ever find yourself adding yet another UserNameDisplayStrategyFactoryFactory just to keep a scenario passing, you will at least have a clear, behavior-centric lens through which to recognize that something has gone wrong.

Design Patterns, Declarative Thinking, and Solving the General Case

Before closing, there is one more point worth addressing, because it tends to resurface in every conversation about abstraction: the role of design patterns. Patterns are often misunderstood in practice. For some teams they become a dictionary of shapes to copy. For others they become a superstition, something to be avoided because they "feel enterprise." In reality, design patterns are nothing more than reusable expressions of relationships that occur frequently in software. They only become harmful when applied without context.

Used well, patterns are a form of declarative modeling. They describe how things relate, not how many classes must be introduced to satisfy a template. This distinction is one reason I created PatternKit
which contains fluent implementations of every GoF pattern. The aim is not to celebrate patterns for their own sake, but to show that they can be expressed clearly and idiomatically, without the ceremony that has accumulated around them over the past few decades. A fluent strategy or builder is readable because it conveys meaning, not because it adheres to a UML diagram. A properly shaped composite or decorator is useful because it matches the problem at hand, not because the catalog says "now is the time."

Patterns at their best are accelerants for thought. They give structure to complex behavior. They reveal seams in the domain. They help us express intent without prescribing a particular class arrangement. When applied declaratively, patterns become lightweight tools that reinforce clarity rather than obstacles that obscure it.

This is the same principle that guides good abstractions. We should always aim to solve the general case when appropriate, rather than re-solving the same narrow problem in twenty different places. Shared operations belong in helpers or extensions not because we want fewer lines of code, but because meaning belongs in one place rather than scattered across many. Wrapping behavior in a well-designed abstraction is not indulgence; it is about shaping the domain so the rest of the system can grow without friction. Once the domain is sufficiently modeled, higher-order helpers, pipelines, or policy objects can provide a unified vocabulary for orchestrating that domain. These are the moments when patterns shine: when they articulate a common structure behind several similar problems and offer a clean way to express the variation between them.

Patterns should not be forced; they should emerge. If you find yourself retrofitting the domain to suit a pattern, the pattern is wrong. If a pattern clarifies the domain, it is the right one. When in doubt, your behaviors and your domain model will tell you the truth.

Closing Thoughts

At every scale, from a one-line helper to a distributed system with dozens of services, the same principles hold. Begin with behavior. Shape abstractions around the real problems rather than your implementation preferences. Allow patterns to emerge naturally when they clarify meaning. Lean on automation and declarative structures to eliminate noise. Let stability arise from good boundaries rather than rigid frameworks. And above all, keep re-examining the domain as it evolves. Systems live for years; code is rewritten many times. The only reliable compass is the domain itself.

You do not hate abstractions. What you hate are the wrong ones: misplaced layers, premature hierarchies, needless ceremony, half-understood patterns applied because someone did not want to think. But abstractions that arise from behavior and domain, shaped carefully and used intentionally, are not burdens. They are the tools that let us build systems that last.

And if you stay anchored to this style of approach, you won’t end up navigating a small cavern system of strategies and factories and wondering how a middle initial turned into a guided tour of every pattern someone ever took a little too seriously. You won’t need to fear abstraction at all. Instead, you will wield it where it belongs.

BDD: Make the Business Write Your Tests

Jerrett Davis — Mon, 01 Sep 2025 22:48:53 +0000

What if the business wrote the tests, and developers just made them pass?

That's the promise of behavior-driven development (BDD). Instead of developers guessing at requirements, chasing
Slack threads, and interpreting vague Jira tickets, we let the people who know the why express it in a form
that's precise enough to execute.

Throughout my career, I've worked with teams of all shapes and sizes, and one pattern is universal:

nobody loves writing tests. Most developers grudgingly agree they're important, but tests are often seen
as a tax—time spent writing code that doesn't "ship features."

The result is predictable: coverage gaps, brittle suites, and requirements that live in Confluence but
never make it into code. Testing becomes a burden instead of a superpower.

BDD flips that dynamic. Instead of treating tests as a chore, it turns them into a shared language between
developers, QA, and the business. Suddenly, everyone is speaking the same language about features and
scenarios, and tests become the living documentation of what the system is supposed to do.

Before we dive into how this works, let's establish a few "Laws of Testing." These aren't divine truths,
but they're a solid starting point—guidelines that help ensure tests actually drive design instead of
just describing what already exists.

The Laws of Testing

No application code will be written until tests are defined.
Systems should be tested as they are meant to be used.
Automate tests to the maximum extent technically and financially feasible.
Every business requirement must have a corresponding test. If the requirement changes, the test must change.
Any code not covered by realistic, automated tests should be treated as magic—and magic should not be trusted.

Notice that I'm not prescribing a specific tool, framework, or level of granularity. These laws simply give you
a pragmatic foundation to make testing a first-class part of building software, not an afterthought.

Behavior-Driven Development

Now for the fun part: putting this into practice.

Behavior-Driven Development (BDD) is designed to bridge the gap between business stakeholders, users, developers,
QA, and everyone else involved in a project. There are many flavors of BDD, but at their core, they all focus on telling
cohesive, testable stories using a shared Domain-Specific Language (DSL).

There's a long-standing joke in IT—still true even in the post-ChatGPT era—that it's easier to teach a subject-matter
expert to code than it is to get them to clearly articulate what they actually want built.

Over the years, countless tools have promised to help non-technical folks bring their ideas to life, but theory and
practice rarely align. Everything works in theory. We can keep building better tools to bridge the gap between
decision-makers and developers, but no tool can prevent the inevitable: requirements change.

Business needs evolve constantly. Even in a perfectly stable market, a company's technology stack would still have to
adapt—whether to security updates, API deprecations, or new compliance requirements. That's why business and technology
teams need a living contract: a shared, human-readable specification of what's supposed to exist, expressed in language
that everyone can understand.

BDD provides exactly that. It takes the "what" from the business and turns it into executable specifications for developers,
ensuring the system stays aligned with today's needs—not just the assumptions written down last quarter.

What BDD Actually Is

Behavior-Driven Development (BDD) is essentially turning your acceptance criteria into executable code.

If your company already writes:

Acceptance Criteria in Jira or Azure DevOps
Business Requirement Documents (BRDs) in Word or Confluence
Test Scripts for QA teams to follow manually

…you're already halfway there. BDD simply takes those artifacts, expresses them in a precise, human-readable format,
and wires them into your test suite so they can be run automatically.

Instead of existing only as text that humans must interpret, your requirements become living specifications that
are always in sync with what the system actually does. If the system drifts, the tests fail — letting you catch gaps
before production users do.

Key ideas:

Ubiquitous language: agree on domain terms and reuse them in requirements, tests, and code.
Outside-in: start from observable outcomes (what users and the business care about) and let those drive your implementation.
Executable documentation: your feature files become a source of truth that stays up to date because failing tests force the team to update them when the business changes its mind.

Why It Clicks with the Business

BDD speaks the same language the business already uses.

Instead of:

"Verify that gold members receive free shipping on orders over $10."

Buried in a PDF or Confluence page, we can write:

Scenario: Gold member gets free shipping
  Given the customer is a "gold" member
  And they have a cart totaling $12.00
  When they checkout with standard shipping
  Then the shipping cost is $0.00
  And the order total is $12.00

Stakeholders can read and confirm this just like they'd review an acceptance test — but now this doubles as a
machine-executable test that can be run in CI.

How to Start Without Overhauling Everything

You don't need to replace all your documentation overnight. Try this:

Take an existing acceptance criterion for a small feature.
Rewrite it as a Gherkin scenario.
Wire up just enough step definitions to make it run.
Let it fail (red).
Write or adjust code until it passes (green).
Refactor code and scenario until both are clear and maintainable.

That's it — you've just done outside-in development. Over time, you can replace more of your static BRDs and
test scripts with living specs that run automatically and stay current.

By framing BDD as an evolution of what teams already do, it becomes less intimidating: you're not adding "one more thing,"
you're making what you already write executable, consistent, and always up to date.

Starting from Existing Code (The Developer + QA Perspective)

Of course, not every team has pristine requirements or well-maintained acceptance criteria.

Sometimes the only source of truth is the code itself, or a set of outdated manual test scripts in a shared folder.

That's okay — you can still apply BDD principles to what you already have.

Step 1: Surface What the Code Already Does

Start by exploring the system from the outside in, and not by reading the code first.

Walk through the application like a user would: click buttons, submit forms, run API calls.
Write down what you observe in plain language, almost as if you were writing a support guide.
Identify key flows: logins, purchases, data exports, admin tasks, error handling.

You're essentially reverse-engineering the behavior that already exists. The goal isn't to perfectly model the internals, but to describe what happens when X occurs.

Step 2: Capture Behavior as Scenarios

Turn those observations into scenarios, even if they're manual at first.

Scenario: User can reset password
  Given I am on the login page
  When I click "Forgot password"
  And I submit my email address
  Then I receive a password reset link by email
  And I can set a new password

This becomes your backfill documentation and a checklist you can use to validate future changes.

Step 3: Choose a Testing Library

Once you have a handful of scenarios, pick a suitable tool that matches your tech stack.
It doesn't have to be fancy — choose something that can:

Parse Gherkin or similar DSL (Cucumber, SpecFlow/Reqnroll, Behave, TinyBDD 😉, etc.)
Run in your CI/CD pipeline
Integrate with the type of app you have (UI automation, API tests, service-level tests)

Don't over-engineer at this stage. The goal is simply to make a scenario run end-to-end.

Step 4: Build Thin Step Definitions

When you wire up steps to code, keep the step definitions thin and reusable:

Treat them like glue code — they orchestrate, not implement.
Push logic into abstractions (page objects, API clients, domain helpers).
Keep language aligned with the business terms you captured earlier.

This separation makes your steps easy to read and your automation maintainable even as your app changes.

Step 5: Automate the Most Valuable Flows First

Don't try to automate everything on day one. Pick a few high-value, low-volatility flows:

Happy-path checkouts
Core login and authentication
Critical reporting or data pipelines

Start small, get them running reliably in CI, and expand gradually. The point is not to hit 100% coverage overnight, but to start to

gain comfort and momentum in writing BDD tests end-to-end.

By working backward from the app's behavior, you create a bridge between what the code does and what the business expects
even when no documentation exists. Over time, your automated scenarios become the new source of truth, letting developers and QA refactor or ship new features with confidence.

Bringing It All Together

Whether you're starting from crisp acceptance criteria or working backwards from a codebase that only lives in developers' heads,
the goal of BDD is the same: close the gap between what the business needs and what the code does.

You don't have to overhaul your entire testing strategy in a single sprint. You just have to start:

Write one scenario.
Get it running end-to-end.
Share it with your team.
Keep going.

Over time, you'll build up a living specification that grows with the system, catching regressions early and making onboarding new developers dramatically easier.

What a Mature BDD Practice Looks Like

A well-adopted BDD process creates a feedback loop that keeps everyone aligned:

Business & product teams write or review scenarios as part of refinement.
Developers implement features by making those scenarios pass.
QA contributes new scenarios for edge cases and validates existing ones stay green.
CI/CD pipelines run the whole suite automatically, so everyone knows the current state of the system at a glance.

When this loop is healthy, you get a shared understanding of what "done" really means, and confidence that your software still works tomorrow, next quarter, and next year.

Final Thoughts

BDD isn't a silver bullet, but it is a forcing function for clearer requirements, more reliable software, and tighter collaboration across teams.

If you've ever wished the business could "just write the tests," BDD is the closest thing we have to that dream. Start small,
stay consistent, and watch as those scenarios turn into a living, breathing specification that guides your development for years to come.

What is "Code"?

Jerrett Davis — Mon, 01 Sep 2025 22:35:00 +0000

Technology is a wonderful thing. Humans, and perhaps even our direct ancestors, have been employing it for millennia. From stone tools to quantum computers, humans can't seem to resist tinkering with whatever the universe gives them.

And with even our most remote, uncontacted relatives still in possession of weapons and shelter, it's safe to say every person on this planet experiences technology from birth to their final days. Right now, as you read this, you're surrounded by, and literally in contact with, an almost uncountable web of human inventions.

Technology shapes our lives, and in turn, we shape its future. It can be used for feats of great creation or acts of horrific destruction. Among all its branches, one of the most powerful and most accessible is code.

You don't need a factory, a lab, or a workshop to work with code. All it takes is a computer and a spark of curiosity. If you've ever stacked LEGO bricks into something from your imagination, built a spreadsheet formula to save hours of work, set a coffee maker to brew before you wake, or fixed something in a pinch with whatever was at hand, you've tapped into the same problem-solving instinct that drives programming.

At its heart, coding is the act of taking what you have and arranging it into something that does what you want. It's imagination with rules, creativity with feedback. And once you've seen something you've built come alive, whether it's a blinking LED, a tool that saves someone's day, or an app that makes a stranger smile, it's hard not to want to build more.

What is "Code"?

Code comes in many flavors. There are programming languages like C#, Assembly, C++, Rust, Python, and countless others, each with its own syntax, style, and purpose. There's G-code, the set of instructions understood by CNC mills, 3D printers, lasers, and other computer-controlled machines. Even music notation is a kind of code, a written sequence of symbols that, when interpreted, produces something meaningful.

The “code” most familiar to all of us is human language. Spoken or written, it can form relationships, transfer knowledge, and inspire change. But language is inherently ambiguous, which makes it ill-suited for telling computers exactly what to do. That's why programming languages exist: precise dialects designed for humans to read and for machines to execute without hesitation or confusion.

Put simply:

Code is a system of signals, symbols, letters, words, or other constructs used to convey a message.

At the very bottom of every modern computer lies binary — two values, usually 1 and 0, representing “on” and “off” or “true” and “false.” Working directly in binary is tedious, so we created layers of abstraction to make our lives easier.

A step above binary is assembly language. Assembly comes in many dialects, each tied to the instruction set of a specific processor. It's still “close to the metal” but far more readable than raw ones and zeros.

A (Somewhat Accurate and Still Overly Dramatic) History of Programming Languages

The history of programming languages is a tapestry of invention, frustration, and the occasional all-nighter. Imagine it told as a fantasy epic.

First came Binary, and from Binary were forged all other tongues of the machine. But the work was slow, and the scribes of silicon longed for an easier way to command their creations.

In the early 1950s, pioneers began to shape new languages: Regional Assembly Language (1951), Autocode (1952), and IPL (1954), the forerunner to LISP. Grace Hopper's FLOW-MATIC (1955) would pave the way to COBOL (1959), while FORTRAN (1957) brought the first compiler to life. The 1960s saw the birth of LISP (1958), ALGOL (1958, 1960), BASIC (1964), PL/I (1964), BCPL (1967), and B (1969), leading to the mighty C (1972).

From the 1970s onward, the floodgates opened: Pascal (1970), Smalltalk (1972), Prolog (1972), SQL (1978), C++ (1980), Ada (1983), Perl (1987), Python (1991), Java (1995), JavaScript (1995), Ruby (1995), PHP (1995), and many more.

Each era brought its own heroes, philosophies, and quirks. Some languages were swift and elegant, others sprawling and stubborn. But all of them, in their way, expanded what was possible.

Today, we live in an age of abundance. We have languages, frameworks, and tools for nearly every conceivable task. And if the exact tool you need doesn't exist, the beauty of code is that you can create it yourself.

Why Code Matters

Code is power, not in the dystopian sense, but in the sense that it lets one person shape behavior, automate work, and solve problems in ways that scale far beyond their own hands.

With code, you can:

Automate boring tasks
Create tools that help people
Control machines in the physical world
Build art, games, and interactive experiences
Invent entirely new kinds of technology

You don't need to be a professional programmer to benefit from learning it. Even small bits of code can make life easier, save time, or open the door to entirely new possibilities.

What's Next?

This post answered “What is code?” in broad strokes: its forms, history, and why it matters. In the next part of this series, we'll start laying the foundations of programming:

Variables & Data Types — the labeled containers of programming.
Operators — the tools for working with your data.
Logic & Flow — the recipes that decide what happens when.

By the time we're done, you'll not just know what code is, you'll be able to write it, read it, and use it to build something that matters to you.

Automating Nightly Local Database Refreshes from Azure Blob Storage with Docker

Jerrett Davis — Thu, 29 Feb 2024 16:54:28 +0000

Background
Prerequisites
Setting up the Docker Container
- Base Dockerfile
- Install Azure CLI
- Install SqlPackage
- Entrypoint
The Scripts
- entrypoint.sh
- initialize-database-and-jobs.sh
- download-latest.sh
- enable-authentication.sql
- reimport-database.sh
- kill-all-connections.sql
- Final Directory Structure and Dockerfile Changes
Building the Docker Container
Testing the Container
Conclusion

Background

In cloud-hosted applications, it is common to restrict access to production databases. This is a good practice, but it can
make it difficult for various teams to access the data they need for development, testing, reporting, and data analysis.
One way to solve this problem is to create a daily process that copies the production database to a location that is accessible
to the teams that need it. In this article, we will create a docker container that will download the latest backup of a
production database from Azure Blob Storage and restore it to a local SQL Server instance.

Prerequisites

This article assumes that you have already set up an automation to back up your production database to Azure Blob Storage.
If you have not done this, you can follow the instructions in this article: Automating Nightly Database Backups to Azure Blob Storage.
The script in the article is reaching end of life, and an updated version can be found here.

Docker must be installed and configured to used Linux containers on your local machine. If you do not
have Docker installed, you can download it from Docker's website.

Setting up the Docker Container

The first step is to create a Dockerfile that will be used to build the container. The Dockerfile will contain the instructions
on how to configure the container and what commands to run when the container is started. For our environment, we will
require Microsoft SQL Server to be installed in the container. We will use the official Microsoft SQL Server Docker image as a base.

Base Dockerfile

Create a new directory on your local machine and create a file called Dockerfile in the directory. Add the following content to the file:

FROM mcr.microsoft.com/mssql/server:2022-CU11-ubuntu-22.04

# Set environment variables for the container
ARG ACCOUNT_NAME
ENV ACCOUNT_NAME=$ACCOUNT_NAME
ARG ACCOUNT_KEY
ENV ACCOUNT_KEY=$ACCOUNT_KEY
ARG CONTAINER_NAME
ENV CONTAINER_NAME=$CONTAINER_NAME

ARG CRON_SCHEDULE="0 4 * * *"
ENV CRON_SCHEDULE=$CRON_SCHEDULE

ARG DATABASE_NAME=MyDatabase
ENV DATABASE_NAME=$DATABASE_NAME
ENV MSSQL_SA_PASSWORD=yourStrong(!)Password
ENV ACCEPT_EULA=Y
ENV MSSQL_PID=Developer

# Create a working directory for our tools and scripts and copy all the files from the host machine to the container
COPY . /sql
WORKDIR /sql

Install Azure CLI

To find and download the latest backup of the production database, we will need to install the Azure CLI in the container.
We'll also need wget, cron, unzip, and a few other utilities to help us automate the process. Microsoft does offer a script
to install the Azure CLI, but in my testing it did not work as expected in the Docker container. Instead, we will use
the manual installation instructions.

Update the Dockerfile to include the following lines after the WORKDIR line:

# Must be root to install packages
USER root

# Install Dependencies
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    unzip cron wget apt-transport-https \
    software-properties-common ca-certificates curl \
    apt-transport-https lsb-release gnupg && \
    rm -rf /var/lib/apt/lists/*

# Install az cli
RUN mkdir -p /etc/apt/keyrings && \
    curl -sLS https://packages.microsoft.com/keys/microsoft.asc | \
        gpg --dearmor | \
        tee /etc/apt/keyrings/microsoft.gpg > /dev/null && \
    chmod go+r /etc/apt/keyrings/microsoft.gpg && \
    AZ_DIST=$(lsb_release -cs) && \
    echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/microsoft.gpg] https://packages.microsoft.com/repos/azure-cli/ $AZ_DIST main" | \
    tee /etc/apt/sources.list.d/azure-cli.list && \
    apt-get update && \
    apt-get install azure-cli && \
    rm -rf /var/lib/apt/lists/*

Install SqlPackage

To import the backup bacpac file that we're going to download from Azure Blob Storage, we will need to install the sqlpackage utility.
This utility is used to import and export bacpac files to and from SQL Server. The utility has evergreen links
available, so we can use the link to download the latest version of the utility.

Add the following lines to the end of the Dockerfile:

# Install SQLPackage for Linux and make it executable
RUN wget -q -O sqlpackage.zip https://aka.ms/sqlpackage-linux \
    && unzip -qq sqlpackage.zip -d /sql/sqlpackage \
    && chmod +x /sql/sqlpackage/sqlpackage \
    && rm sqlpackage.zip

The above lines download the latest version of the sqlpackage utility from Microsoft's website, unzip it, make it executable, and then remove the zip file.

Entrypoint

Finally, we need to add our entrypoint script to the container. This script will be run when the container starts, and it
will perform all the necessary steps to download the latest backup from Azure Blob Storage and restore it to the local SQL Server instance.

Add the following lines to the end of the Dockerfile:

# Switch back to mssql user
USER mssql

EXPOSE 1433

CMD /bin/bash ./entrypoint.sh

We need to switch back to the mssql user to run the SQL Server process, so we make use of the USER command to do this.
The EXPOSE command tells Docker that the container listens on the specified network ports at runtime.
The CMD command specifies the command that will be run when the container starts. In this case, we are running the entrypoint.sh script.

We will make some final changes to our Dockerfile later, but for now, save the file and close it.

The Scripts

As we alluded to at the end of our Dockerfile, we need to create an entrypoint.sh script that will be run when the container starts.
Since this container is based on the official Microsoft SQL Server Docker image, we need to ensure the original entrypoint is also run
alongside our custom entrypoint script. To do this, we need to create an additional script that we will call in our entrypoint.sh script.

entrypoint.sh

Create two new files in the same directory as your Dockerfile called entrypoint.sh and initialize-database-and-jobs.sh.
Add the following content to entrypoint.sh:

#!/bin/bash
/sql/initialize-database-and-jobs.sh & /opt/mssql/bin/sqlservr

You'll note that we are running the initialize-database-and-jobs.sh script in the background and then starting the SQL Server process.
This & syntax is necessary to ensure that the original entrypoint script is also run without the docker container exiting immediately after
the script completes.

initialize-database-and-jobs.sh

Add the following content to initialize-database-and-jobs.sh:

#!/bin/bash

# wait 30 seconds for SQL Server to start up
echo "Waiting for SQL Server to start"
sleep 30s

# Download the bacpac file from the Azure Blob Storage
echo "Downloading bacpac file from Azure Blob Storage"
bash /sql/download-latest.sh $ACCOUNT_NAME $ACCOUNT_KEY $CONTAINER_NAME /sql/backup.bacpac
backupJob=$?

if [ "$backupJob" -eq 0 ]
then
    echo "Successfully downloaded bacpac file from Azure Blob Storage!"
    echo "Enabling SQL Server authentication..."
    /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P $MSSQL_SA_PASSWORD -d master -i /sql/enable-authentication.sql
    echo "SQL Server authentication enabled. Waiting for 10 seconds before importing the bacpac file..."
    sleep 10s

    # Import the bacpac file into the SQL Server
    /sql/sqlpackage/sqlpackage /a:import /sf:/sql/backup.bacpac /tsn:localhost,1433 /tdn:$DATABASE_NAME /tu:sa /tp:$MSSQL_SA_PASSWORD /ttsc:True

    # Set up 4am CRON job to re-import the database
    echo "$CRON_SCHEDULE /bin/bash /sql/reimport-database.sh" | crontab -
    echo "CRON job set up successfully"
    exit 0
else
    echo "Failed to download bacpac file from Azure Blob Storage"
    exit 1
fi

This short script does quite a few operations. First, it's recommended to wait for SQL Server to start up before attempting to connect to it.
We set up a 30-second timer to wait for SQL Server to start. We then download the latest backup from Azure Blob Storage using the download-latest.sh script.
If the download is successful, we use the built-in sqlcmd utility to enable SQL Server authentication. We then wait for 10 seconds to ensure that the
SQL Server has stabilized. We then use the sqlpackage utility to import the bacpac file into the SQL Server. Finally, we set up a CRON job to run the
reimport-database.sh script at a frequency specified by the CRON_SCHEDULE environment variable. We then exit the script with a success code.

We need to create the download-latest.sh and reimport-database.sh scripts that are called in the initialize-database-and-jobs.sh script.

download-latest.sh

Create a new file called download-latest.sh and add the following content:

#!/bin/bash

# Description: This script downloads the latest backup from an Azure Storage Account
# Usage: bash DownloadLatest.sh <storageAccountName> <storageAccountKey> <containerName> <localPath>

accountName=$1
accountKey=$2
containerName=$3
localPath=${4:-"./backup.bacpac"}

# Get the name of the latest blob
firstBlob=$(az storage blob list --account-key $accountKey --account-name $accountName -c $containerName --query "[?properties.lastModified!=null]|[?ends_with(name, '.bacpac')]|[0].name" -o tsv)

# Check if $firstBlob is not null (i.e., there are blobs found)
if [ -n "$firstBlob" ]; then
    az storage blob download --account-key $accountKey --account-name $accountName -c $containerName --name $firstBlob --file $localPath --output none
    exit 0
else
    exit 1
fi

The Azure CLI lets us write queries to filter the results of the az storage blob list command. The queries are written in
JMESPath, which is a query language for JSON. In this case, we are filtering the results to only include blobs that end with the
.bacpac extension and then selecting the first one as ordered by the lastModified property. If there are no blobs found, the script exits with a failure code.
If we find a blob, we download it to the local path specified by the localPath variable.

enable-authentication.sql

Create a new file called enable-authentication.sql and add the following content:

sp_configure 'contained database authentication', 1;
GO
RECONFIGURE;
GO

This script enables contained database authentication in the SQL Server instance. This is necessary to allow the sa user to authenticate to the database
when importing the bacpac file.

reimport-database.sh

Create a new file called reimport-database.sh and add the following content:

#!/bin/bash

echo "Downloading bacpac file from Azure Blob Storage"
bash /sql/download-latest.sh $ACCOUNT_NAME $ACCOUNT_KEY $CONTAINER_NAME /sql/backup.bacpac
backupJob=$?
if [ "$backupJob" -eq 0 ]
then
    echo "Successfully downloaded bacpac file from Azure Blob Storage!"
    echo "Kill all connections to the database"
    /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P $MSSQL_SA_PASSWORD -d master -i /sql/kill-all-connections.sql
    databaseName=$DATABASE_NAME
    existingDatabaseName="${databaseName}_$(date +%s)"
    echo "Renaming existing database to $existingDatabaseName"
    /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P $MSSQL_SA_PASSWORD -d master -Q "ALTER DATABASE $databaseName MODIFY NAME = $existingDatabaseName;"
    echo "Renamed existing database to $existingDatabaseName"
    echo "Importing bacpac file into the SQL Server"
    /sql/sqlpackage/sqlpackage /a:import /sf:/sql/backup.bacpac /tsn:localhost,1433 /tdn:$DATABASE_NAME /tu:sa /tp:$MSSQL_SA_PASSWORD /ttsc:True
else
    echo "Failed to download bacpac file from Azure Blob Storage"
    exit 1
fi

You'll notice that this script is very similar to the initialize-database-and-jobs.sh script. The main difference is that we are renaming the existing database
before importing the new bacpac file. This is necessary because the sqlpackage utility does not support overwriting an existing database.
We also need to kill all connections to the database before renaming it. We do this by running a SQL script that we will create called kill-all-connections.sql.

kill-all-connections.sql

Create a new file called kill-all-connections.sql and add the following content:

-- kill all connections to the database
DECLARE @killCommand NVARCHAR(MAX) = '';

SELECT @killCommand = @killCommand + 'KILL ' + CAST(spid AS VARCHAR) + ';'
FROM sys.sysprocesses
WHERE dbid > 4;

EXEC sp_executesql @killCommand;

As its name suggests, this script kills all connections to the database. This is necessary to ensure that we can rename the database without any active connections.

Final Directory Structure and Dockerfile Changes

If everything went to plan, your directory should look like this:

.
├── Dockerfile
├── entrypoint.sh
├── initialize-database-and-jobs.sh
├── download-latest.sh
├── enable-authentication.sql
├── reimport-database.sh
├── kill-all-connections.sql

Now before we can build the Docker container, we need to make a few final changes to our Dockerfile.
We need to copy all the files from our local machine to the container and set the correct permissions on the scripts.
Add the following lines to your Dockerfile directly after the USER root line:

RUN mkdir /home/mssql && chown mssql /home/mssql && \
    chmod +x /sql/initialize-database-and-jobs.sh && \
    chmod +x /sql/entrypoint.sh && \
    chmod +x /sql/download-latest.sh

The mkdir command creates a new directory in the container and the chown command changes the owner of the directory to the mssql user.
We then set the correct permissions on the scripts using the chmod command. Save the Dockerfile and close it.

Building the Docker Container

Now that we have all the necessary files, we can build the Docker container. Open a terminal and navigate to the directory where your Dockerfile is located.
Run the following command to build the container:

docker build -t azure-local-database-refresh .

This command will build the container using the Dockerfile in the current directory and tag the container with the name azure-local-database-refresh.
The build process may take a few minutes to complete. Once it's done, you can run the container using the following command:

docker run -e ACCOUNT_NAME=<storageAccountName> -e ACCOUNT_KEY=<storageAccountKey> -e CONTAINER_NAME=<containerName> -e DATABASE_NAME=MyDatabase -p 1433:1433 -it  azure-local-database-refresh

Replace <storageAccountName>, <storageAccountKey>, and <containerName> with the appropriate values for your Azure Blob Storage account. The -p flag maps port 1433 of the container to port 1433 of your local machine.
This allows you to connect to the SQL Server instance running in the container from your local machine. The -it flag runs the container in interactive mode, which allows you to see the output of the container in your terminal.

You should see the output of the container in your terminal. If everything is working correctly, you should see messages indicating that the bacpac file has been downloaded and imported into the SQL Server instance. The import
process can take a several minutes to complete, depending on the size of the database. Once the import process is complete, you should see a message indicating that the CRON job has been set up successfully.

Testing the Container

Now that we have our container up and running, we can test it by connecting to the SQL Server instance and verifying that the database has been restored.
Open a new terminal and run the following command to connect to the SQL Server instance running in the container:

docker exec -it <containerId> /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -P yourStrong(!)Password

Replace <containerId> with the ID of your container. This command will open an interactive SQL Server prompt. Run the following command to verify that the database has been restored:

SELECT name FROM sys.databases;

If everything went to plan you should see the name of your database in the output. You can also run queries against the database to verify that the data has been restored correctly.

Conclusion

In this article, we created a Docker container that automates the process of downloading the latest backup of a production database from Azure Blob Storage and restoring it to a local SQL Server instance.
We used a combination of bash scripts and Docker to create a portable and easy-to-use solution that can be run on any machine that has Docker installed. This solution can be used to provide teams with access
to the latest production data for development, testing, reporting, data analysis, or other internal uses. The container can be run on a schedule using a CRON job to ensure that the data is always up-to-date. This solution can be
easily extended to support other databases and cloud storage providers.

The code for this solution is available on GitHub.
This docker container is also available on Docker Hub.