Phase 10: Tooling API for developer workflows

[rianjs]

Summary

• Add Tooling API client (api/tooling/) for developer workflow operations
• Add sfdc apex commands: list, get, execute, test
• Add sfdc log commands: list, get, tail
• Add sfdc coverage command with minimum threshold support

New Commands

Apex Operations

sfdc apex list                          # List Apex classes
sfdc apex list --triggers               # List Apex triggers
sfdc apex get MyController              # Get class source code
sfdc apex execute "System.debug('Hi');" # Execute anonymous Apex
sfdc apex test --class MyTest --wait    # Run Apex tests

Log Operations

sfdc log list                           # List debug logs
sfdc log get 07L1x000000ABCD            # Get log content
sfdc log tail                           # Stream new logs

Coverage

sfdc coverage                           # Show all coverage
sfdc coverage --class MyController      # Coverage for specific class
sfdc coverage --min 75                  # Fail if below threshold

Test plan

• All existing tests pass
• New Tooling API client tests pass
• New command tests pass
• Linter passes

Closes #20

🤖 Generated with Claude Code

[rianjs]

Test Coverage Assessment for PR #25: Tooling API for Developer Workflows

Summary

This PR adds substantial new functionality (Tooling API client, Apex commands, Log commands, Coverage command) with good overall test coverage. The tests follow established patterns using httptest for mocking and table-driven tests. However, there are some gaps worth noting.

---

What's Well Covered

Tooling API Client (api/tooling/client_test.go - 477 lines)

• Client creation validation (missing instance URL, missing HTTP client)
• All major API methods: ListApexClasses, ListApexTriggers, GetApexClass, ExecuteAnonymous, RunTestsAsync, GetTestResults, ListApexLogs, GetApexLogBody, GetCodeCoverage, GetAsyncJobStatus
• Not-found scenarios (GetApexClassNotFound)
• Compile error response parsing (ExecuteAnonymousCompileError)
• API error handling (401 responses)

Apex Commands (internal/cmd/apexcmd/apex_test.go - 379 lines)

• List classes (table and JSON output)
• List triggers
• Get class source
• Execute success/compile error/stdin paths
• Test enqueue (no-wait mode)

Coverage Command (internal/cmd/coveragecmd/coverage_test.go - 328 lines)

• List all coverage
• Coverage for specific class
• Minimum threshold pass/fail
• JSON output
• Empty coverage data
• Class not found

Log Commands (internal/cmd/logcmd/log_test.go - 294 lines)

• List logs with limit
• Get log content
• JSON output
• Empty log list
• Helper functions (formatSize, truncate)

---

Coverage Gaps

1. sfdc log tail command has no test coverage

• internal/cmd/logcmd/tail.go (104 lines) is completely untested
• This is the most significant gap - it has a polling loop, context cancellation handling, and seen-logs tracking

2. sfdc apex test --wait path is untested

• The --wait flag triggers displayTestResults() which polls job status and displays results
• Only the no-wait path (TestApexTestNoWait) is tested
• The polling loop and result display logic are untested at the command level (though GetTestResults is tested at the client level)

3. sfdc apex get --trigger path is untested

• The --trigger flag in get.go calls GetApexTrigger instead of GetApexClass
• Client-level test exists but command-level test doesn't cover the trigger path

4. Runtime error path in sfdc apex execute is untested

• Tests cover compile errors but not runtime exceptions (result.Success = false with ExceptionMessage)

5. No tests for sfdc apex get --output <file> (file output)

• The --output/-f flag writes to a file instead of stdout

---

Pragmatic Assessment

Should these gaps block merge? No, for these reasons:

1. The core business logic is well-tested - API client methods, record parsing, output formatting
2. The happy paths are covered for all commands
3. The untested code is primarily I/O orchestration (polling loops, file I/O, context handling) which is harder to unit test and less likely to have subtle bugs
4. Test coverage for this PR (~1,478 lines of tests for ~2,791 lines of code) is above average for CLI tools

Recommended follow-up (non-blocking):

• Add a basic test for tail command that verifies initial setup and first poll
• Add test for --wait flag exercising the polling/display path
• These could be added in a follow-up PR without blocking this one

---

Code Quality Notes

• Tests use httptest.NewServer consistently for mocking - good pattern
• Table-driven tests used appropriately (TestFormatSize, TestTruncate)
• Testify assertions used throughout
• Test client injection via SetToolingClient() enables clean command testing

[rianjs]

Addressed the TDD assessment feedback by adding tests for:

• sfdc apex get --trigger path
• sfdc apex execute runtime error handling
• sfdc log tail context cancellation