Skip to content

test(analytics): verify runtime semantics of account-filter integration tests #32

Description

@cristim

Context

golangci-lint v2 (landed in LeanerCloud/cloud-commitments-cli#1137) type-checks //go:build integration files. This exposed that the internal/analytics integration tests (postgres_analytics_db_test.go, postgres_analytics_integration_test.go) were written against a removed QueryRequest.AccountID API and the old single-string account signatures of QueryByProvider / QueryByService / QueryMonthlyTotals. They had not compiled since the account-filter model changed to AccountUUIDs + AccountExternalIDsByProvider.

A compile-fix PR restores type-checking (so CI Lint passes) by mechanically remapping the removed account arg to:

AccountExternalIDsByProvider: map[string][]string{"aws": {"<acct>"}, "gcp": {"<acct>"}}

for every query call/struct, keyed under both providers the suite uses.

What this issue tracks (NOT done in the compile-fix PR)

These integration tests run only under Docker/testcontainers (CI Lint just type-checks them), so the compile-fix did not verify their runtime behavior. The account-filter area has historically broken silently (see the global lesson: four successive "fixes" merged green while the bug survived because tests filtered the wrong column). So before trusting these tests:

  • Run the suite with Docker (go test -tags=integration ./internal/analytics/) and confirm each t.Run still asserts the intended rows.
  • Verify the AccountExternalIDsByProvider remap matches each test's saved snapshot providers (the blanket {"aws","gcp"} mapping may over- or under-match a block that previously filtered account-wide or by a single provider).
  • Confirm the AccountUUIDs vs AccountExternalIDsByProvider choice is correct per case (snapshots are saved with an external account id, not a UUID).
  • Add at least one assertion that would FAIL if the account filter matched the wrong column (regression guard for the documented trap).

Acceptance

Integration tests pass under Docker AND a deliberately-wrong account filter makes them fail (proving they actually exercise the filter).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions