byop-engine/docs/golang-analyzer-testing.md

Golang Analyzer Testing Guide

This guide provides ways to test the Golang analyzer functionality without making API calls, enabling faster development and debugging.

Quick Testing

Run All Tests

# Run all Golang analyzer tests
go test ./analyzer/stacks/golang/ -v

# Or use the convenience script
./scripts/test-golang-analyzer.sh

Run Specific Test Categories

# Test main package detection (fixes the "configs" vs "cmd/web-server" issue)
go test ./analyzer/stacks/golang/ -run TestFindMainPackage -v

# Test the specific web server structure that was failing
go test ./analyzer/stacks/golang/ -run TestWebServerProjectStructure -v

# Test full LLB generation pipeline
go test ./analyzer/stacks/golang/ -run TestIntegrationLLBGeneration -v

# Test CGO detection and handling
go test ./analyzer/stacks/golang/ -run TestCGODetection -v

Test Coverage

Unit Tests (golang_test.go)

• ✅ Basic functionality: TestGolang() - Name and basic operations
• ✅ Project analysis: TestAnalyze() - Detects Go projects vs non-Go projects
• ✅ Main package detection: TestFindMainPackage() - Finds correct main package in various structures
• ✅ Project analysis: TestAnalyzeGoProject() - Full project analysis including modules, ports, dependencies
• ✅ LLB generation: TestGenerateLLB() - Basic LLB generation
• ✅ Web server structure: TestWebServerProjectStructure() - Specific test for the failing case

Integration Tests (integration_test.go)

• ✅ Full LLB pipeline: TestIntegrationLLBGeneration() - Complete end-to-end LLB generation
• ✅ CGO detection: TestCGODetection() - Tests CGO environment variable handling

Key Fixes Validated by Tests

1. Main Package Detection Fix

Problem: System was detecting configs as main package instead of cmd/web-server

Solution: Enhanced findMainPackage() to:

• Look for main function in Go files, not just any .go files
• Exclude non-executable directories like configs
• Properly traverse cmd/ subdirectories

Test: TestWebServerProjectStructure() validates this specific case

2. Environment Variable Handling

Problem: CGO_ENABLED=0 GOOS=linux ... was being treated as a command instead of environment variables

Solution: Separated environment variables from shell command using llb.AddEnv()

Test: Build commands in integration tests validate proper environment handling

3. Directory Creation

Problem: /app directory might not exist when copy operations run

Solution: Explicitly create /app directory before copying files

Test: Integration tests validate the full build pipeline

Manual Testing Scenarios

Create Test Project Structure

# Create a test project that mimics the failing structure
mkdir -p /tmp/test-golang-project/{cmd/web-server,configs,pkg/mhttp}

# Create go.mod
echo "module test-web-server
go 1.21" > /tmp/test-golang-project/go.mod

# Create main file
echo "package main
func main() {}" > /tmp/test-golang-project/cmd/web-server/main.go

# Create config file (should NOT be detected as main)
echo "package configs
var Config = map[string]string{}" > /tmp/test-golang-project/configs/server.go

# Test analysis
cd /home/ray/byop/byop-engine
go run -c "
import './analyzer/stacks/golang'
g := &golang.Golang{}
result := g.findMainPackage('/tmp/test-golang-project')
fmt.Printf('Main package: %s\n', result)
"

Validate LLB Generation

# Test LLB generation without BuildKit
go test ./analyzer/stacks/golang/ -run TestGenerateLLB -v

# The test will show:
# - LLB definition size in bytes
# - Validation that it's proper JSON
# - Basic structure validation

Development Workflow

1. Make changes to golang.go
2. Run tests with go test ./analyzer/stacks/golang/ -v
3. Check specific functionality with targeted test runs
4. Validate with integration tests before API testing

Benefits of This Testing Approach

• ⚡ Fast: No network calls or BuildKit operations
• 🔍 Focused: Test specific functionality in isolation
• 🐛 Debuggable: Easy to add debug output and inspect intermediate results
• 🔄 Repeatable: Consistent test environments
• 📊 Comprehensive: Cover edge cases that might be hard to reproduce via API

Next Steps for Production Testing

Once unit tests pass, you can validate with the actual API:

1. Deploy changes to your development environment
2. Test with real Go projects
3. Monitor build logs for the corrected main package detection
4. Verify no more "no Go files in /app" or "configs is not in GOROOT" errors