Add comprehensive unit tests and performance optimizations for prometheus-to-sd

[erain]

Summary

This PR adds comprehensive test coverage and performance optimizations to the prometheus-to-sd component, significantly improving code quality, reliability, and performance.

🎯 Motivation

After a thorough code review of the prometheus-to-sd codebase, I identified critical areas needing improvement:

1. Missing Test Coverage: Several core functions had no unit tests, making them prone to regressions
2. Performance Bottlenecks: Inefficient string concatenation and map allocations in hot paths
3. Edge Case Gaps: Error handling scenarios were not tested

✨ Key Changes

📝 New Unit Tests (755 lines added)

1. config/common_config_test.go (New)

Tests for parseAuthConfig function with complete coverage:

• ✅ Empty auth configuration handling
• ✅ Token-based authentication
• ✅ Basic authentication (username/password)
• ✅ Token file reading with whitespace trimming
• ✅ Error handling for non-existent token files
• ✅ Edge cases with empty token files

2. config/gce_token_source_test.go (New)

Tests for AltTokenSource.token() method:

• ✅ Successful token retrieval from mock server
• ✅ HTTP error response handling
• ✅ Invalid JSON response handling
• ✅ Missing access token scenarios
• ✅ Token expiry validation
• ✅ Multiple token fetches behavior

3. translator/prometheus_test.go (Enhanced)

Comprehensive tests for PrometheusResponse.Build():

• ✅ Valid Prometheus metrics parsing
• ✅ Summary metrics flattening to _sum/_count
• ✅ Invalid content type error handling
• ✅ Malformed metrics parsing errors
• ✅ Component name omission feature
• ✅ Metric name downcasing feature
• ✅ Whitelisted metrics filtering
• ✅ Custom metrics prefix handling
• ✅ Empty response handling
• ✅ Histogram metrics processing
• ✅ Untyped metrics handling

⚡ Performance Optimizations

1. String Concatenation (config/dynamic_source.go:71-86)

Before: O(n²) complexity

var nameList string
for _, key := range keys {
    nameList += key + ","
}

After: O(n) complexity

var nameList strings.Builder
for _, key := range keys {
    nameList.WriteString(key)
    nameList.WriteString(",")
}

Impact:

• Reduces time complexity from O(n²) to O(n)
• Critical for nodes with many dynamic sources
• Eliminates unnecessary string copies in the hot path

2. Map Allocation (translator/translator.go:218, 234)

Before: Lazy allocation without capacity hint

res := map[string]*dto.MetricFamily{}

After: Pre-allocated with capacity hint

res := make(map[string]*dto.MetricFamily, len(whitelisted))

Impact:

• Reduces memory allocations
• Improves cache locality
• Prevents map rehashing during metric filtering

🧪 Testing

All tests pass successfully:

ok   github.com/GoogleCloudPlatform/k8s-stackdriver/prometheus-to-sd/config      0.020s
ok   github.com/GoogleCloudPlatform/k8s-stackdriver/prometheus-to-sd/flags       (cached)
ok   github.com/GoogleCloudPlatform/k8s-stackdriver/prometheus-to-sd/translator  0.026s

📊 Benefits

Category	Improvement
Test Coverage	+755 lines of unit tests
String Concatenation	O(n²) → O(n) time complexity
Map Allocations	Pre-allocated, reduced reallocation
Edge Cases	Comprehensive error handling coverage
Maintainability	Tests serve as living documentation

📦 Files Changed

New Test Files

• prometheus-to-sd/config/common_config_test.go
• prometheus-to-sd/config/gce_token_source_test.go
• prometheus-to-sd/translator/prometheus_test.go (enhanced)

Optimized Files

• prometheus-to-sd/config/dynamic_source.go
• prometheus-to-sd/translator/translator.go

🔒 Compatibility

✅ No breaking changes - All optimizations maintain full backward compatibility
✅ Zero functional changes - Only tests and performance improvements
✅ All tests pass - Verified against existing test suite

🎓 Design Decisions

1. Why strings.Builder? It's the idiomatic Go approach for repeated string concatenation, providing significant performance benefits without sacrificing readability.

2. Why pre-allocate maps? Go maps grow by doubling, so pre-allocation with the exact capacity needed prevents intermediate reallocations.

3. Why mock HTTP server? Allows deterministic testing of token source behavior without requiring actual GCE credentials.

---

Contributors: Yu Yi yiyu@google.com

Thank you for reviewing this PR! All feedback is welcome.