Introduce fakes and contract tests for AWS Lambda integration

[tooky]

Context

Addresses #758. Our cloud provider integration tests all call real external services, causing flaky CI, slow feedback, and poor edge-case coverage. This PR establishes the pattern for fixing that, starting with AWS Lambda as the template.

The approach follows Steve's comment on #758: Fakes (not mocks) kept honest by contract tests that run the same suite against both the fake and the real implementation.

What this PR introduces

1. LambdaAPI interface (internal/aws/aws.go)

A narrow interface scoped to the two SDK methods we actually call:

type LambdaAPI interface {
    ListFunctions(ctx, params, optFns...) (*ListFunctionsOutput, error)
    GetFunctionConfiguration(ctx, params, optFns...) (*GetFunctionConfigurationOutput, error)
}

The real *lambda.Client satisfies this implicitly — no adapter needed. Internal helpers (getFilteredLambdaFuncs, getAndProcessOneLambdaFunc, getLambdaPackageDataFromClient) accept the interface instead of concrete types.

2. FakeLambdaClient (internal/aws/fake_lambda.go)

An in-memory implementation of LambdaAPI with:

• Marker-based pagination (configurable page size)
• Error responses for missing functions
• GetFunctionConfigurationErr field for error injection in tests

3. Contract test suite (internal/aws/lambda_contract_test.go)

A shared runLambdaContractTests(t, client, existingFunctionName) function that exercises the behaviours we depend on:

• ListFunctions returns results
• Pagination via MaxItems + Marker
• GetFunctionConfiguration for existing function returns config with CodeSha256 and LastModified
• GetFunctionConfiguration for missing function returns error

This suite runs against both the fake (always) and real AWS (env-gated behind AWS_ACCESS_KEY_ID). If both pass, the fake is a trustworthy stand-in. If the real side drifts, the contract catches it.

4. Fake-backed unit tests (internal/aws/aws_test.go)

Filtering tests (11 cases): IncludeNames, IncludeNamesRegex, ExcludeNames, ExcludeNamesRegex, combined filters, multi-page pagination with filtering, empty results, invalid regex errors.

Orchestration tests (5 cases): Zip fingerprint decoding, Image raw CodeSha256, concurrent multi-function processing, empty function list, error propagation from GetFunctionConfiguration.

These all run without AWS credentials and complete in milliseconds.

5. Package-level factory for command-test injection (internal/aws/aws.go)

var NewLambdaClientFunc = defaultNewLambdaClient

func ResetLambdaClientFactory() { ... }

GetLambdaPackageData uses NewLambdaClientFunc instead of creating a client directly. This follows the existing codebase pattern (package-level globals for logger, kosliClient, global).

6. Command tests decoupled from AWS (cmd/kosli/snapshotLambda_test.go)

SetupTest injects a FakeLambdaClient seeded with two functions (cli-tests as Zip, cli-tests-docker as Image). TearDownTest resets the factory. All 14 test cases now run without AWS credentials — the requireAuthToBeSet / SkipIfEnvVarUnset pattern is removed entirely.

7. Trimmed integration tests

Lambda integration tests reduced from 8 cases to 3 focused smoke tests (invalid credentials, one Zip happy path, one Image happy path). Filtering and orchestration logic is now covered by fast fake-backed tests.

8. make test_smoke_aws Makefile target

Runs contract tests and smoke tests against real AWS — intended for use before releases:

make test_smoke_aws  # requires AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY

Test layers after this PR

Layer	Runs when	AWS creds needed	Kosli server needed
Fake-backed unit tests (internal/aws/)	Always	No	No
Contract tests — fake (internal/aws/)	Always	No	No
Contract tests — real (internal/aws/)	make test_smoke_aws	Yes	No
Smoke tests (internal/aws/)	make test_smoke_aws	Yes	No
Command tests (cmd/kosli/)	make test_integration	No	Yes

Next steps (tracked in TODO.md)

This PR establishes the pattern. The remaining cloud providers follow the same structure:

1. ECS — highest complexity (nested clusters → services → tasks concurrency)
2. S3 — paginator-based pattern differs from marker-based
3. Azure Apps — multiple client interfaces (ARM + Container Registry)
4. Docker — simplest (no pagination or concurrency)
5. Kubernetes — semaphore-based concurrency, KIND cluster for contract tests

Each is broken down into slices in TODO.md.

How to review

The commits are structured as thin vertical slices — each is independently reviewable:

1. 7416da85 — Pure refactoring: extract LambdaAPI interface, change signatures
2. c9f70331 — Contract test suite wired to real AWS
3. 9b892595 — FakeLambdaClient passes the same contract
4. d3f7fa20 — 11 fake-backed filtering/pagination tests
5. 4e9789f6 — 5 fake-backed orchestration tests
6. 0c87bc5a — Trim integration tests from 8 → 3
7. ef346fe0 — Factory injection into command tests, remove credential gating

🤖 Generated with Claude Code

[claude]

Claude finished @jumboduck's task in 2m 15s —— View job

---

PR Review: Introduce fakes and contract tests for AWS Lambda integration

• Phase 1: Static analysis (go build, go vet, go mod tidy)
• Phase 2: Code review of changed files
• Phase 3: Post review findings

---

Phase 1: Static Analysis

All three checks pass cleanly:

• go build ./... — compiles without errors
• go vet ./... — no issues
• go mod tidy — no missing or unused dependencies

Phase 2: Code Review

This is a well-structured PR that establishes a solid pattern for decoupling cloud provider tests from real AWS. All previously accepted review suggestions (error-type comment, t.Skip pagination guard, skipIfCredsUnset rename, MaxItems upper-bound fix) have been implemented in the latest commits. I have no blocking issues.

What works well:

• Contract test design — runLambdaContractTests as a shared suite running against both the fake and real AWS is textbook contract testing. The t.Skip guard for single-function accounts makes the real-AWS path resilient to environment drift.
• Clean interface extraction — LambdaAPI is scoped to exactly the two methods the codebase uses. No unnecessary abstraction.
• Fake fidelity — FakeLambdaClient implements marker-based pagination, MaxItems upper-bound, and error responses. The error-type divergence comment (fake_lambda.go:82) is a good breadcrumb for future developers.
• Test layering — The PR creates clear separation: fast fake-backed unit tests (always), contract tests (always for fake, env-gated for real), smoke tests (env-gated). This is the right pyramid.
• Factory injection + teardown — SetupTest/TearDownTest in snapshotLambda_test.go properly injects and resets the factory global, preventing test pollution.

Minor observations (all non-blocking):

1. fakeLambdaClientWithFunctions uses invalid base64 (aws_test.go:603) — The helper sets codeSha256 := "abc123" which isn't valid base64. This is fine because filtering tests only check function names, not fingerprints. But if someone reuses this helper for orchestration tests, base64 decoding would fail silently. The orchestration tests correctly use proper values — just a footgun to be aware of.

2. Fake field coverage — GetFunctionConfiguration in fake_lambda.go:74-79 copies only 4 fields (FunctionName, CodeSha256, LastModified, PackageType). If production code ever reads additional fields (e.g. Runtime, Handler), the fake returns zero values without error. The contract test would catch this for the real side, but not the fake side. This is fine for the current scope.

3. Recursive pagination — getFilteredLambdaFuncs (aws.go:173-207) uses recursion for pagination. With thousands of Lambda functions and a 50-function page size, this could theoretically stack overflow — but this is pre-existing behavior, not introduced by this PR, and unlikely in practice.

Phase 3: Summary

This is a well-executed PR. The fakes-and-contracts pattern is a proven approach for decoupling from external services, and the implementation here is clean, thorough, and consistent with codebase conventions. The test coverage is comprehensive (11 filtering + 5 orchestration + 4 contract + 14 command tests), and the test_smoke_aws Makefile target provides a clear path for pre-release validation against real AWS.

No blocking issues. Looks good to merge.