Skip to content

[test] Add tests for guard.parseResourceResponse and guard.parseCollectionLabeledData#2717

Merged
lpcox merged 1 commit intomainfrom
test/coverage-guard-parse-functions-445255d6b6f14f74
Mar 28, 2026
Merged

[test] Add tests for guard.parseResourceResponse and guard.parseCollectionLabeledData#2717
lpcox merged 1 commit intomainfrom
test/coverage-guard-parse-functions-445255d6b6f14f74

Conversation

@github-actions
Copy link
Copy Markdown
Contributor

Test Coverage Improvement

Functions Analyzed

  • Package: internal/guard
  • Functions: parseResourceResponse and parseCollectionLabeledData
  • Previous Coverage: 0% (both functions had no unit tests)
  • Complexity: High — combined 19+ branches, nested type assertions, loop iterations, and default value paths

Why These Functions?

Both functions are called in the hot path of the LabelResponse method on WasmGuard, which is invoked for every tool response that passes through a WASM security guard. Despite their centrality, they had zero direct test coverage. They contain complex branching logic (type assertions, nested maps, array iteration with per-element type checks) that is easy to break silently.

Tests Added (internal/guard/wasm_response_parse_test.go)

TestParseResourceResponse — 20 table-driven cases:

  • ✅ Full resource with description, secrecy/integrity tags, and each operation type
  • ✅ All four operation strings: "read", "write", "read-write", and missing/unknown (default to write)
  • ✅ Case-sensitivity: uppercase "READ" defaults to write
  • ✅ Empty secrecy/integrity arrays produce empty labels
  • ✅ Missing secrecy/integrity keys use default empty labels
  • ✅ Non-string tags in arrays are silently skipped
  • ✅ Non-array secrecy/integrity values fall back to empty label
  • ✅ Non-string description fields are safely ignored
  • ✅ Missing resource key → error
  • ✅ Wrong-type resource value (string, array, number, nil) → error

TestParseResourceResponse_OperationCoverage — 6 focused cases covering every operation branch

TestParseCollectionLabeledData — 22 table-driven cases:

  • ✅ Empty and nil items slices → empty collection
  • ✅ Non-map items (strings, numbers, booleans, nil, arrays) → silently skipped
  • ✅ Mixed map/non-map items → only maps included, order preserved
  • ✅ Items without labels key → Labels field is nil
  • ✅ Non-map labels value → Labels field is nil
  • ✅ Empty labels map → default empty secrecy/integrity labels
  • ✅ Full labels: description, multiple secrecy/integrity tags
  • ✅ Partial labels: secrecy only, integrity only, description only
  • ✅ Non-string tags skipped; all-non-string array → empty label
  • ✅ Non-array secrecy/integrity → default empty label
  • data field variety: nil, string, nested map, missing key
  • ✅ 5-item collection preserves insertion order

TestParseCollectionLabeledData_CollectionInterface — verifies *CollectionLabeledData satisfies difc.LabeledData interface (compile-time + runtime contract)

TestParseResourceResponse_ReturnTypeSanity — verifies Contains() lookups on returned labels

Coverage Impact

Before: 0% on parseResourceResponse and parseCollectionLabeledData
After:  ~100% branch coverage on both functions

Generated by Test Coverage Improver
Next run will target the next most complex under-tested function

Generated by Test Coverage Improver ·

…beledData

These two functions in internal/guard/wasm.go were completely untested
despite having high cyclomatic complexity:

- parseResourceResponse: 8 branches across resource map validation,
  description/secrecy/integrity tag parsing, and operation type switching
- parseCollectionLabeledData: 11+ branches with nested type assertions,
  array iteration, and per-item label parsing

New test file covers:
- Happy paths: full labels, partial labels, empty labels
- All four operation types (read, write, read-write, default)
- Non-string tags silently skipped in secrecy/integrity arrays
- Non-map item entries silently skipped in collection
- Non-array secrecy/integrity values default to empty labels
- Non-string description fields gracefully ignored
- Missing/nil/wrong-type resource key returns error
- Empty and nil items slices produce empty collections
- Multiple items with mixed label configurations
- LabeledData interface contract validation

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@lpcox lpcox marked this pull request as ready for review March 28, 2026 14:49
Copilot AI review requested due to automatic review settings March 28, 2026 14:49
@lpcox lpcox merged commit 71fc0db into main Mar 28, 2026
3 checks passed
@lpcox lpcox deleted the test/coverage-guard-parse-functions-445255d6b6f14f74 branch March 28, 2026 14:49
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds comprehensive unit tests for the WASM guard response parsing helpers in internal/guard, improving coverage for logic used on the WasmGuard.LabelResponse hot path.

Changes:

  • Introduces extensive table-driven tests for parseResourceResponse, including operation parsing and type-safety cases.
  • Adds extensive table-driven tests for parseCollectionLabeledData, including mixed item types, label parsing behavior, and order preservation.
  • Adds interface/return-type sanity checks for returned labeled data structures.
Comments suppressed due to low confidence (1)

internal/guard/wasm_response_parse_test.go:308

  • This test function name duplicates an existing TestParseCollectionLabeledData in internal/guard/guard_test.go (around line 942). The package will not compile with both present. Rename this test (e.g., TestParseCollectionLabeledData_Comprehensive) or consolidate with the existing one.
func TestParseCollectionLabeledData(t *testing.T) {
	tests := []struct {
		name           string

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.


// ─── parseResourceResponse ────────────────────────────────────────────────────

func TestParseResourceResponse(t *testing.T) {
Copy link

Copilot AI Mar 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test function name duplicates an existing TestParseResourceResponse in internal/guard/guard_test.go (around line 802). Go will fail to compile with duplicate declarations in the same package. Rename this test (e.g., TestParseResourceResponse_Comprehensive) or remove/merge the older test so only one remains.

This issue also appears on line 306 of the same file.

Suggested change
func TestParseResourceResponse(t *testing.T) {
func TestParseResourceResponse_WASM(t *testing.T) {

Copilot uses AI. Check for mistakes.
Comment on lines +307 to +313
tests := []struct {
name string
items []interface{}
wantItemCount int
wantErr bool
checkItems func(t *testing.T, collection *difc.CollectionLabeledData)
}{
Copy link

Copilot AI Mar 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wantErr is never set to true in this table, and parseCollectionLabeledData currently never returns an error. Consider removing wantErr (and the associated branch) to reduce noise, or add explicit error cases if you expect the function to start returning errors later.

Copilot uses AI. Check for mistakes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants