Phase 8: REST API commands

[rianjs]

Summary

• Add sfdc query command for SOQL queries with pagination and queryAll support
• Add sfdc record command with get, create, update, delete subcommands
• Add sfdc search command for SOSL text search across objects
• Add sfdc object command with list, describe, fields subcommands
• Add sfdc limits command to display org API limits
• Add Search method and SearchResult type to api package

Commands Added

Query

sfdc query "SELECT Id, Name FROM Account"
sfdc query "SELECT Id FROM Account" --all  # include deleted
sfdc query "SELECT * FROM Opportunity" -o json

Record

sfdc record get Account 001xx000003DGbYAAW
sfdc record create Account --set Name="Acme Corp"
sfdc record update Account 001xx000003DGbYAAW --set Phone="555-1234"
sfdc record delete Account 001xx000003DGbYAAW --confirm

Search

sfdc search "Acme"
sfdc search "John Smith" --in Account,Contact

Object

sfdc object list
sfdc object describe Account
sfdc object fields Account --required-only

Limits

sfdc limits
sfdc limits --show DailyApiRequests

Test Plan

• All new commands have unit tests with mocked API responses
• make build succeeds
• make test passes
• make lint passes

Closes #18

[rianjs]

Test Coverage Assessment for PR #23

This PR adds significant functionality to the CLI: five new command packages (querycmd, recordcmd, searchcmd, objectcmd, limitscmd) plus supporting API code. I've reviewed both the code changes and the test coverage.

Overall Assessment: Good Coverage

All tests pass, and the coverage metrics for new code are solid:

• limitscmd: 91.5%
• querycmd: 88.0%
• searchcmd: 88.5%
• objectcmd: 82.6%
• recordcmd: 68.3%
• api package: 78.8%

Strengths

1. Command-level tests are well structured - Each command package has comprehensive tests covering happy paths, error conditions, JSON output, and flag variations.

2. HTTP mocking is done correctly - Tests use httptest.NewServer to mock Salesforce API responses, which is the right approach.

3. Edge cases for helper functions are tested - parseSetFlags in recordcmd has thorough tests for various input formats (quoted strings, booleans, null values, invalid formats).

4. formatFieldValue tests cover multiple types (nil, string, float64, bool, nested objects).

5. buildSOSL tests verify SOSL query construction with different flag combinations.

Areas for Consideration

1. SearchRecord.UnmarshalJSON (api/types.go) - This custom unmarshaler is new but lacks a direct unit test in types_test.go. While it's exercised through the search command tests, a dedicated test would catch edge cases like:

   • Malformed JSON
   • Missing attributes or Id fields
   • Various field types in the dynamic fields map

2. api.Client.Search method - No direct test in client_test.go. It's tested indirectly via searchcmd, but a unit test would verify URL encoding and error handling at the client level.

3. Delete confirmation prompt (recordcmd/delete.go) - The interactive prompt reads from os.Stdin directly rather than using the injectable opts.Stdin. This makes the non-confirm path untestable and is why recordcmd has lower coverage (68.3%). Consider using opts.Stdin for consistency with the Options pattern used elsewhere.

4. Error paths in create command - When result.Success is false, errors are displayed but the function returns nil rather than an error. This seems intentional but could use a test to document the behavior.

5. queryAllRecords function - Uses a direct path /queryAll but no test verifies the URL encoding works correctly with special characters in the SOQL.

Verdict

The test coverage is adequate for merging. The tested behaviors cover the critical paths a user would exercise. The gaps noted above are minor and don't represent significant risk:

• The custom unmarshalers are exercised through integration-style tests
• Error handling follows established patterns in the codebase
• The main functionality paths are all tested

The lower coverage on recordcmd is primarily due to the interactive delete prompt, which is a reasonable testing limitation.

Recommendation: Approve with consideration for future improvements to the delete command's testability.