When Your Source Generator Creates More Coupling Than It Solves: Designing for Testability

Source generators are a fantastic way to eliminate boilerplate. But there's a dark side: they can quietly introduce coupling that makes your tests brittle or impossible to write. I've seen teams adopt generators with enthusiasm, only to find their test coverage plummet because the generated code depends on internal states, static singletons, or specific ordering of generator runs. This isn't a failure of generators as a concept—it's a failure of design. In this article, I'll show you how to spot those coupling patterns and, more importantly, how to design generators that respect testability.

The core idea is simple: treat your generator like any other component. Give it clear boundaries, inject what it needs, and test its output in isolation. But the devil's in the details—how do you test something that runs at compile time? How do you mock a generated class? Let's dig in.

Who Needs This and What Goes Wrong Without It

Teams using .NET incremental generators who struggle with unit tests

If you're the person who writes source generators—or the team that depends on them—you probably feel the pain before you name it. You add a generator, it emits code, and suddenly your unit tests start feeling brittle. Not because your business logic changed. Because the generator changed. I've seen this pattern at three different shops now: a team adopts incremental generators to reduce boilerplate, and within two sprints the test suite is the bottleneck. Who needs this? Anyone whose .g.cs files trigger test failures that have nothing to do with the feature under test. That includes backend teams generating serialization code, API clients, or dependency injection wiring—plus front-end teams doing command mapping or route registration. The audience is wider than you'd expect: if your generator output touches any public API that tests exercise, you're in the danger zone.

Common symptoms: generated code tightly coupled to static state

The classic smell is a generator that reads DateTime.UtcNow, Environment.GetEnvironmentVariable, or a static config singleton during generation. That sounds fine until the test runner's clock drifts or CI uses a different timezone. Worse: generators that bake absolute paths or machine-specific GUIDs into output. I once debugged a generator that pulled a tenant ID from a static dictionary—every test run on a different developer's box produced different output hashes. The generated code wasn't deterministic, and neither were the tests. The catch is that incremental generators encourage caching, but caching on mutable static state creates invisible coupling. What usually breaks first is the assertion that compares a generated string—one build says "ConnectionString_Prod," the next says "ConnectionString_Dev." That's not a test failure; it's a design debt.

'We thought the generator was just plumbing. Then every PR with a generator update required re-writing 40 test assertions.'

— Lead dev, after three sprints of coupling pain

The cost: fragile tests that break on generator updates

The real damage isn't the broken test itself—it's the lost trust. Once developers learn that test failures are often false alarms from generator drift, they start ignoring red builds. "Oh, that's just the generator again." That hurts. A team that treats generator-related test failures as noise is a team that will miss real regressions. The cost compounds: each generator version bump demands manual verification of output, mocking becomes a nightmare when static state is involved, and code coverage reports become useless because they lump generated code with authored code. And here's the kicker—most teams don't realize the coupling exists until they try to parallelize tests or switch to a different hosting environment. Then the seams blow out. One rhetorical question worth asking: how much of your test suite would survive if you regenerated all output from scratch tomorrow? If the answer scares you, keep reading.

Prerequisites: What You Should Have in Place First

What You Actually Need Before Touching the Generator

You need a working .NET project that already consumes at least one source generator—ideally a simple one like [AutoNotify] or a custom partial-class filler. I have seen teams jump straight into writing a generator that produces 400 lines of glue code, only to realize they never checked whether the consuming project could even find the generated output during a clean build. That hurts. More importantly, you must understand the difference between incremental generators (the IIncrementalGenerator interface, .NET 6+) and the older ISourceGenerator approach. The incremental model caches intermediate results; the classic model re-runs everything on every keystroke. If you don't know which one your solution uses, the debugging flow described later in this article will feel like guessing in the dark.

Second, you need a solid grip on dependency injection—not just the syntax, but the why. Most generator testability problems trace back to coupling that DI patterns could have prevented: a generator that hard-codes a file path, or one that calls DateTime.Now inside a syntax receiver. The catch is that source generators can't use DI containers at build time—they run in a stripped-down compiler process—so the patterns shift. Instead of constructor injection, you use well-factored helper classes that accept GeneratorExecutionContext as a parameter. A rhetorical question worth asking: if your generator logic is too tangled to test in isolation, did you really have a testable design anywhere in the project? I'd argue no. Most teams skip this prerequisite and end up writing integration tests that take forty seconds to spin up—and they run them only after the generator breaks production builds.

Tooling That Saves Your Week

Install the Microsoft.CodeAnalysis.CSharp.SourceGenerators.Testing NuGet package before you write a single unit test—yes, before. The official GeneratorDriver classes let you run a generator against a string of source code and inspect the resulting Compilation. Without that, you'll cobble together hacky console apps that write generated files to disk, then manually diff them. I once spent three days on a custom test rig that the team threw away when we discovered the testing package existed. The trade-off: the testing package is heavy—it pulls in Roslyn internals—and slows down your test suite if you run hundreds of cases. However, the slower tests still beat the alternative (no tests at all). You'll also want a reference to Xunit or NUnit for assertions, plus Verify (from VerifyTests) if you plan to snapshot-test generated output. That's three dependencies, not a mountain—but they're non-negotiable if testability is your goal.

One final reality check: your environment must support running generators in a non-hosted context—meaning a test runner that can load Roslyn assemblies. This fails silently on older .NET Framework test adapters. I have seen a team waste a morning debugging a null reference exception in a generator test, only to discover the test project targeted net48 while the generator assembly required .NET 6 APIs. Wrong order. The fix: target net8.0 or later for test projects, and set true in the generator's project file. Checklist-style: one SDK project, one test project, one generator project—each with explicit target frameworks. Don't assume the test project inherits the generator's version. It won't.

Most generator failures aren't logic bugs—they're environment misalignment: wrong NuGet version, missing attribute, or a syntax receiver that triggers on the wrong node kind.

— common pattern from GitHub issues on the dotnet/roslyn-sdk repo, paraphrased

Reality check: name the development owner or stop.

Core Workflow: Designing a Generator for Testability

Step 1: Separate generation logic from application logic

The single biggest mistake I see in source generator projects is mixing what the generator does with how it builds the output. You end up with a monolithic class that collects syntax, transforms data, and concatenates strings — all inside the same method. That hurts. When something breaks, you can’t tell whether the syntax walker failed, the transformation blew up, or the string builder emitted malformed code. The fix is ruthless separation: pull your data-mapping logic into pure functions that accept input objects and return intermediate models. Keep the syntax traversal in one module, the code emission in another. Most teams skip this — they think "it's just a small generator" until the first bug costs them a day of debugging.

Here's the rule I apply: if I can't unit-test the transformation logic without triggering a full compilation, the design is wrong. Write a method that takes a Dictionary<string, string> and returns a List<PropertyDef> — no GeneratorExecutionContext needed. Test that in isolation. Then test that your syntax walker correctly populates that dictionary from a known syntax tree. Suddenly your generator is a stack of testable slices, not a hard-to-debug blob.

Step 2: Use interfaces for generated types

The generated code itself creates coupling. If your generator emits concrete classes and everything references them directly, you can't swap them for test doubles. The catch is — most tutorials skip the interface layer entirely. They show you how to create a partial class and call it done. That works until you need to test something that consumes that generated type. I have seen teams write integration tests that compile the generator, run it, then instantiate the output — fragile and slow.

Instead, make your generator emit an interface plus a default implementation. Yes, it's an extra line of generated code. But consider the payoff: your production code depends on ICustomerService, not CustomerService. Your unit tests can inject a mock. The generated impl still wires up automatically at build time. One caveat — don't generate interfaces that change signature with every build. That defeats the purpose. Design the contract to be stable, and let the implementation absorb the churn.

Step 3: Test the generator output as a string or syntax tree

What breaks first when you refactor a generator? The emitted code changes shape — whitespace, ordering, or naming drifts — but the consuming code worked fine. That's a false positive. The generator still runs, but your tests never noticed the output mutated. Here's what I do: after generating, capture the output as a string and compare it to a baseline snapshot. Not the compiled assembly — the raw text. Why? Because a single missing semicolon or wrong casing in a property name might compile fine but break runtime binding. Snapshot testing catches that.

Alternatively, parse the output into a SyntaxTree and walk it with assertions. "Does this class have a constructor with three parameters?" "Does the generated ConfigureServices method call AddScoped at least once?" You can write these as standard xUnit or NUnit tests — fast, no compilation required. The trade-off: snapshot files accumulate. Prune them ruthlessly when the contract changes. And

Never trust a generator test that doesn't inspect the output — passing the build step only means C# swallowed it, not that your logic is correct.

— lead engineer on a failed migration, looking at green CI

Step 4: Verify generated code compiles and passes assertions

Okay — you've separated logic, used interfaces, and tested the output string. Is that enough? Not quite. A generator that emits syntactically valid but semantically wrong code will still compile. I have debugged generators that generated int EmployeeId { get; set; } for every property because a null reference snuck in during metadata collection. The snapshot looked fine — same property name, same type — but the values were all mapped to the wrong column.

So step four: add a compilation test that loads your generator in a separate process (using GeneratorDriver), runs it against a known input, compiles the result, and then executes a small assertion — "does the generated SqlBuilder return the correct SQL for this test model?" This is heavier than snapshot testing. You'll need a test project with the generator referenced as an analyzer. But it catches the bugs that snapshot tests miss. Run it only on critical paths; don't make every property test a full compilation. That would slow your feedback loop to a crawl. Pragmatism wins: one integration-style test per generator feature, snapshot tests for the rest.

Tools, Setup, and Environment Realities

Required NuGet packages: Microsoft.CodeAnalysis.CSharp.SourceGenerators.Testing

You need exactly two packages to stop guessing whether your generator works. Microsoft.CodeAnalysis.CSharp.SourceGenerators.Testing gives you the test harness — a driver that feeds fake syntax trees to your generator and lets you inspect the output. Pair it with Microsoft.CodeAnalysis.CSharp.SourceGenerators.Testing.Xunit if you're on xUnit (most teams are). The catch? Version mismatches. I have seen three teams burn half a sprint because their test project pulled Microsoft.CodeAnalysis.Common 4.8 while the generator targeted 4.5. The compiler silently skips your tests. Pin the Roslyn SDK version explicitly in your Directory.Build.props — one number, one source of truth.

The real work isn't installing packages. It's wiring the test project so it actually runs the generator. Most devs slap a unit test on a string of source code and call it done. That misses the point — your generator doesn't exist in isolation. It reads attributes, sees partial classes, maybe pulls files from embedded resources. Without those dependencies, your test compiles a fantasy world. We fixed this by building a shared GeneratorTestDriver class that preloads every assembly reference the generator touches. Painful to set up. Worth it when the third iteration of a feature doesn't silently regress.

Configuring test projects to reference the generator as an analyzer

Here's where people trip: a source generator isn't a library reference. It's an analyzer reference. Your test project's .csproj needs this:

<ItemGroup> <ProjectReference Include="..\MyGenerator\MyGenerator.csproj" OutputItemType="Analyzer" ReferenceOutputAssembly="false" /> </ItemGroup>

Wrong order. ReferenceOutputAssembly="false" tells the compiler "don't link the DLL as a normal reference, just run it during compilation." Miss that flag and your test compiles but the generator never fires. Or worse — it fires twice. The testing NuGet package handles this internally when you use CreateGeneratorDriver, but only if you pass the generator instance directly. Most teams skip this: they rely on the package's default references, then wonder why generated symbols are missing at compile time. What usually breaks first is the ISourceGenerator interface — if your generator targets the incremental API (IIncrementalGenerator), the older testing package silently drops it. Upgrade to at least version 1.1.1.

Odd bit about development: the dull step fails first.

Writing a test base class that compiles generated code and runs assertions

The brittle way: copy-paste a GeneratorDriver setup into every test file. The better way: one base class that owns the compilation pipeline. Here's the skeleton we use:

public abstract class GeneratorTestBase { protected static Compilation CreateCompilation(string source) { var references = new[] { MetadataReference.CreateFromFile(typeof(object).Assembly.Location), MetadataReference.CreateFromFile(typeof(MyAttribute).Assembly.Location) }; return CSharpCompilation.Create("test", new[] { CSharpSyntaxTree.ParseText(source) }, references); } protected static GeneratorDriver CreateDriver(ISourceGenerator generator) { return CSharpGeneratorDriver.Create(generator); } }

That sounds fine until you need to test a generator that reads analyzer config options or debug flags. Then the base class needs a way to pass AnalyzerConfigOptions into the driver. We added a virtual method protected virtual AnalyzerConfigOptionsProvider GetOptions() that returns default values. Subclasses override it to inject test-specific settings. One team I worked with forgot this entirely — their generator silently swallowed missing config and produced zero output. Took three days to trace because the test passed (empty output matched empty expectations).

'A generator test that never fails is worse than no test — it trains your team to ignore the build output.'

— senior dev, during a particularly painful post-mortem

The assertion part? Don't just check that output files exist. Verify symbols are accessible. Use Compilation.GetSymbolsWithName() to confirm your generated class has the right methods, the right access modifiers, the right base types. A test that only checks string output catches typos but misses structural regressions — like when a refactor changes a generated type from public to internal and your consuming code silently breaks at runtime.

Variations for Different Constraints

When you can't modify the generated code (third-party generators)

You inherit a source generator from another team—or worse, a NuGet package you can't fork. The generated classes are sealed, internal, or emit code that refuses to cooperate with your test harness. What usually breaks first is the inability to inject a stub because the generator hardcodes constructor calls or static factory methods. I have seen teams waste two weeks trying to wrap generated types in adapters, only to discover the generator also produces extension methods that bypass the wrapper entirely. The workaround: write a test seam at the call site, not at the generator output. Create an interface that mirrors the generated type's public surface, then build a handwritten adapter that implements that interface by delegating to the generated code. Yes, it's duplication—but it isolates your tests from the generator's coupling. The catch is that this strategy collapses if the generator adds members in a patch release; your interface becomes a liability. Monitor the generator's changelog, and pin the package version in your test project explicitly.

Testing generators that depend on external files or configurations

Your generator reads appsettings.json, a YAML schema, or a CSV mapping file at design time. That sounds fine until CI builds fail because the test runner's working directory doesn't match the generator's file resolution path. The pitfall: source generators execute inside the compiler's pipeline, not your test process—file paths that work in dotnet test from the terminal can yield null references when run from an IDE test runner or a Docker container. Most teams skip this: they mock the file reader interface inside the generator's plumbing. But what if the generator is sealed and the file-reading logic is inlined? Then you're stuck. One concrete fix: extract the file-loading step into a virtual method that your test subclass can override—even if you have to fork the generator's source for a week. Alternatively, use a post-compile test that spins up a minimal host project, copies the external file into its output directory, and triggers the generator via a real build call. That hurts—it adds seconds to every test run—but it catches path mismatches before production. A rhetorical question worth asking: is your generator's dependency on external files a design choice or an accident of convenience?

Handling generators that produce multiple files or partial classes

Partial classes across five generated files, each depending on the other—test isolation becomes a jigsaw puzzle. The first mistake: writing a single test that asserts against the aggregate output. You lose the ability to pinpoint which file introduced the bug. Instead, test each generated file independently by feeding your generator a minimal input and intercepting its output per file. I have used an in-memory AdditionalTexts provider that simulates exactly one GeneratedFile at a time—everything else throws FileNotFoundException so I know when cross-file dependencies sneak in. The trade-off: this exposes whether your generator's internal ordering is stable. If file B reads from file A's emitted constants, you must either order the test sequence or refactor to a shared-interface pattern. One team I worked with discovered that their generator emitted partial classes in alphabetical file name order—fine on Windows, broken on Linux where case sensitivity flipped the sequence. They fixed it by writing a deterministic ordering method, then tested it with a custom comparer that deliberately scrambled file names. That said, you don't need to test every permutation; test the boundary cases: one file, maximum files (whatever your generator's pragmatic limit is—often 50), and a file that depends on a prior file that was never generated. The last case should throw—and if it doesn't, you've found a silent coupling.

'We stopped testing generated files individually because it felt redundant. Then a two-line change in an upstream partial broke our entire build silently.'

— Senior engineer at a fintech shop, after three rollback-caused incidents

Pitfalls, Debugging, and What to Check When It Fails

Accidental static state in generators that breaks isolation

Nothing derails a generator test faster than a static cache that refuses to clear between runs. The IncrementalSourceGenerator API leans on immutable state — but I've watched teams smuggle mutable singletons into helper classes, convinced they'd save milliseconds. They don't. What happens is test #1 populates static ConcurrentDictionary, test #2 expects empty, and you spend an afternoon chasing phantom failures. The fix is boring but reliable: inject a fresh context per generation pass. If you absolutely need caching, use the IncrementalValueProvider pipeline — it handles staleness for you. One team I worked with had a static HashSet<string> accumulating assembly names across test runs. Every fourth test passed; the rest blew up. We moved the set into the Compilation object's metadata cache, and suddenly tests became deterministic. That's the trade-off — performance caches bought you nothing if you can't trust the output.

Generated code that references internal or private types

Your generator emits FooHelper — but FooHelper is internal in the source project. The compile stage passes; the generator test runner sees no error. Then you deploy, and the downstream assembly gets CS0122 at runtime. Ouch. The root cause? Generator tests often compile against the generator's own assembly, not the consuming project's public surface. Most teams skip this: they verify syntax, not symbol accessibility. What to check — run your test's Compilation with WithOptions(outputKind: OutputKind.DynamicallyLinkedLibrary) and set internalsVisibleTo only when the generator owns the assembly. Otherwise, emit a diagnostic. One concrete step: add a SymbolAction that flags any generated member whose DeclaredAccessibility is Internal and whose containing symbol is not the generated compilation. That catches the leak before it ships.

Debugging generator output by inspecting syntax trees or written files

When a test fails and you don't know why, don't poke at the Roslyn symbol table blind. Write the generated source to disk inside the test — File.WriteAllText("dump.g.cs", syntaxTree.ToString()). Yes, it's ugly. Yes, it works. I've seen people spend three hours stepping through SemanticModel.GetDeclaredSymbol calls only to discover their generator emitted partial class Foo : Foo. One look at the file would have saved two hours. The catch is your CI pipeline might not have write permissions — guard it with #if DEBUG. A better long-term move: pipe the generated tree into a SyntaxTreeComparer that diffs against a golden file. That way you catch regressions in formatting or missing members automatically. The format test sits alongside your unit tests, not buried in a manual walkthrough.

Not every development checklist earns its ink.

'Generators are easy to write and hard to test — the asymmetry catches everyone once.'

— reflection after rewriting a serialization generator for the third time

What usually breaks first is the mismatch between how your generator runs in the IDE and how it runs in a test harness. The IDE pipelines cache aggressively; test runners might reset compilations per iteration. Use GeneratorDriver with RunGenerators in your test — that mirrors the real pipeline, including incremental caching. If a test passes in isolation but fails in a batch, suspect shared state. If it passes only in a specific order, you have a static leak. And if the generated file looks correct but referencing code won't compile — check accessibility again. The pattern is stubborn: you'll fix one leak, and another surfaces in the next sprint. That's normal. Debugging generator tests is brute-force pattern matching, not art. Write the file, check the access level, isolate the cache. Repeat until green. Then lock that test as a regression guard.

FAQ and Checklist in Prose

Can I unit test a generator without compiling?

Short answer: yes, but it's not the kind of unit test you're used to. You can—and should—test the generator's syntax-tree manipulation logic in isolation by feeding it an InputCompilation built from strings, not real project files. The tricky bit is that GeneratorExecutionContext demands a compilation object, which itself requires at least a minimal syntax tree. Most teams skip this: they wait until the generator runs inside a real build, then debug by staring at generated files. That hurts. I have seen teams burn two days hunting a null-reference crash that a three-line string-based test would have caught in thirty seconds.

Build a test helper that constructs a CSharpCompilation from a snippet of source code—no disk I/O, no NuGet restore. You'll pass that compilation to your generator's Execute method, then inspect the added SourceText objects. The catch? You can't test runtime behavior of the generated code this way—that's what conventional integration tests are for. But you can verify that the generator emits the right class name, the correct number of methods, and no malformed syntax. One concrete anecdote: we fixed a bug where a generator emitted a partial class with a duplicate member by adding exactly this kind of string-based test. Without it, the team would have shipped a broken incremental build.

How do I mock a generated class?

You don't. Mocking a generated class is a sign that your design is coupling the generator's output to test infrastructure in the wrong direction. Instead, extract an interface from the generated code—either by convention (the generator always emits IGeneratedService) or by emitting a base class. Then your unit tests depend on the interface, not on a concrete generated type that may change every time the generator evolves. That sounds fine until you realize the interface itself must be shipped as a NuGet package alongside the generator, creating a versioning headache. The trade-off is worth it: we've seen projects where every generator change broke fifteen mock assemblies. Extracting a stable interface cut that to zero.

What usually breaks first is the assumption that generated classes are easy to substitute in test containers. They aren't—because the generator often wires up dependency injection or internal state that the test can't replicate. If you really need to test against the generated implementation, do it in an integration test that compiles both the generator and its consumer, then runs assertions on the compiled assembly. Not fast, but accurate. A quick fragment for your mental checklist: If mocking a generated class feels awkward, you probably need a seam—not a mock.

— Lead engineer, after the third mock assembly rebuild in one sprint

Checklist: 5 things to verify before merging a generator change

Condensed from months of painful debugging, these checks catch the most common regressions. First, does the generator still run in incremental mode without forcing a full recompilation on unrelated edits? Miss this, and your team will every developer's machine grind to a halt. Second, can you compile the generated output in isolation—no warnings, no hidden CS0103 or CS0117? Roslyn's generator is optimistic about what the compiler will resolve; we have been burned by generated code that references types the project doesn't reference.

Third, what happens when the generator receives no inputs—empty compilation, zero types to inspect? Many generators crash with a null reference on the first .Where(...) over an empty collection. Fourth, are your test assertions checking the shape of the generated source (class name, method signatures) and not just that no exceptions throw? Passing doesn't mean correct output. Fifth, and this is the one most people skip: run the generator against a project that uses global using directives or implicit usings. Those often change the namespaces the generator sees, causing partial class splits that break the build silently. Before you merge, open the generated file in a real project and confirm it compiles alongside hand-written code. Do that, and you'll save yourself the awkward "why did CI fail for everyone?" Slack message. Your next step: write the string-based unit test for your most fragile syntax-tree transformation today—not after the next incident.

What to Do Next (Specific Actions)

Add snapshot testing to your generator tests

Stop scrolling. Open your generator test project and install Verify or Snapshooter right now — I'll wait. Snapshot testing catches the silent regressions that unit tests miss: the one-line formatting shifts, the accidental namespace change, the missing partial modifier. We fixed a two-week debugging cycle last year by snapping the entire generated output of a Roslyn source generator against a known-good baseline. The catch? Snapshots rot if you update them without reviewing the diff. Never approve a snapshot without reading every changed line — treat it like a code review, not a checkbox. Start with one generator method, snap its output for three input variants (empty, minimal, real-world), and let CI fail when the diff surprises you. That alone kills 80% of coupling regressions before they ship.

Build a test harness that runs generators on sample code

Most teams skip this: a dedicated CSharpGeneratorDriver wrapper that runs your generator against a hello-world project, a real-world project, and a deliberately broken project. I have seen teams waste three days because they only tested against their production codebase — then a new consumer added a syntax tree with #line directives and everything exploded. Wrong order. You need a harness that feeds raw syntax trees, not just compilation units. The trade-off is maintenance: your test projects become a second codebase that drifts from reality. Fix that by pulling two sample files from your actual consumers (with permission, anonymized) and running them in CI weekly. The pitfall is over-engineering — a harness that mocks ISyntaxReceiver callbacks but never hits the real Execute path misses the coupling you're trying to test. Keep the harness thin: one method that accepts a string of source code, runs the generator pipeline, and returns the generated trees as strings. That's it.

'Test the generator the way your consumers do — from raw source to emitted output, skipping nothing but the disk.'

— senior engineer who once shipped a generator that silently dropped partial classes for six weeks

Share your patterns with your team to standardize generator design

One team I coached had four different generator architectures across six projects. Each used a different pattern for caching, a different convention for ISyntaxReceiver registration, and a different way to pass AnalyzerConfigOptions. That hurts. Coupling wasn't in the generated code — it was in the mental overhead required to debug any of them. Write a one-page ADR (Architecture Decision Record) that dictates: "We always separate ISyntaxReceiver from ISourceGenerator, we always accept an OptionsProvider interface for config, and we always expose a testable Transform method that takes a SyntaxNode and returns string?." Enforce it in PR — have a linter rule or a reviewer checklist that flags generators mixing concerns. The fragility is that rigid standards calcify as requirements shift — allow opt-out with a written justification. But honestly, standardization here cuts the time-to-debug from hours to minutes. Start tomorrow's standup with: "Show me your generator's test harness or tell me why you don't have one." That's the action. Not "we'll discuss it in the next sprint" — Tuesday morning, ten minutes, concrete proof. Do it.