How We Test

What's covered

• Tax documents: create, replace, commit, credit, void, idempotent replays, PendingTax fallback
• FX: daily rate table, same-day lock sharing, weekend/holiday fallback, rounding
• Every request validator (field-level messages, camelCase paths)
• The simulated tax engine and rate source the demo relies on
• Sales-tax, by-jurisdiction and vendor-tax reports
• The Bank of Canada client at the HTTP boundary (stubbed handler)
• The job scheduler with a fake clock: no real waiting, no flakiness

Example

[Fact]
public async Task Replaying_the_same_request_is_idempotent()
{
    await _host.SeedEntityAsync();
    var (first, _) = await _host.Get<TaxService>().CreateAsync(Invoice(), Ct);

    var (second, outcome) = await _host.Get<TaxService>().CreateAsync(Invoice(), Ct);

    outcome.ShouldBe(TaxDocumentOutcome.Unchanged);
    second.Id.ShouldBe(first.Id);
    _host.Provider.Requests.Count.ShouldBe(1); // Avalara called once
}

Building blocks

• WebApplicationFactory hosts the API in memory; tests call it over HTTP like a client
• Testcontainers starts postgres:17 once per run; each test class gets its own database
• WireMock.Net plays AvaTax, with responses in the documented v2 shapes, so the real SDK, retries and error mapping run
• A test auth handler issues scoped callers, so permissions are tested too

Highlights

• Two requests racing for the same FX lock get the same rate (Postgres advisory lock)
• An Avalara outage saves the bill as PendingTax, and the retry recovers it under the same document code
• Vendor sync sends only code, name, address and email, never proprietary data
• Redelivered messages don't create duplicate documents (inbox/outbox)

Example: the AvaTax adapter against a stub

Stub("PUT",  "/api/v2/companies/1001/vendors/V-100", 404, NotFound);
Stub("POST", "/api/v2/companies/1001/vendors", 200, CreatedVendor);

var response = await client.PutAsJsonAsync(
    "/api/v1/entities/PVC/vendors/V-100",
    new UpsertPartyRequest("ABC Plumbing", Columbus, "ap@abc.example"));

(await response.ReadAsync<PartyDto>()).SyncStatus
    .ShouldBe(PartySyncStatus.Synced);

Suites (tests/e2e)

• playground: key gate (locked, wrong key, unlock, remembered), FX rate, tax estimate, record + credit, validation errors, reports, the guys
• api: health, 401 without a key, Server-Timing, estimates, idempotent documents, problem details; safe as a post-deploy smoke test
• vpw: the Vendor Portal Wizard summons three vendors and sends them back
• accessibility and responsive (Pixel 7): see below

No retries: a flaky E2E test gets fixed, never retried, because retries hide exactly the bugs these tests exist to catch. Failures keep a trace, screenshot and HTML report.

Example

test("records a document, then credits it", async ({ page }) => {
  await unlock(page);
  await page.locator("#document-form .send").click();
  await expectStatus(page, "document", 201);
  await expect(page.locator("#lastDoc")).toContainText("Committed");

  await page.locator('[data-doc-action="credit"]').click();
  await expectStatus(page, "document", 201);
});

Coverage gate (a ratchet)

Floors only go up. build/coverage-gate.py merges unit and integration coverage and writes this table into every CI run's summary.

Always on

• Warnings are errors; .NET analyzers at latest-recommended
• Vulnerable NuGet packages (including transitive) fail the build
• Dependabot opens weekly update PRs (NuGet, npm, Actions, Docker), and every one runs this whole pipeline
• Deterministic tests: fake clocks, per-class databases, no sleeps, no retries
• Health checks: /health/live, /health/ready (database), /health/providers