Second Brain

For Apex test-class deployment via Salesforce MCP, split monolithic te…

2 min read

For Apex test-class deployment via Salesforce MCP, split monolithic te…

Decision

For Apex test-class deployment via Salesforce MCP, split monolithic test-class rewrites into a new supplementary class containing additions plus helper, with surgical patches to the existing class deployed separately. Use locally-built deployment zips (Python zipfile with explicit cls-meta.xml) routed through sf_deploy_metadata rather than sf_write_apex_class or sf_build_deploy_package.

Rationale

Three failures observed in this session forced the workaround. First, sf_write_apex_class failed with STRING_TOO_LONG because the MetadataContainer name (Apex prefix plus class name plus 10-digit timestamp) hits 34 chars vs Salesforce 32-char max for class names of 18+ chars. Second, sf_build_deploy_package generates zips with empty cls-meta.xml content, rejected by the Metadata API as INVALID_OPERATION invalid zip file. Third, embedding 218KB base64 zip body in a single MCP tool call exceeds practical output budget. Splitting into a supplementary class isolates risk (one deploy can fail without blocking the others), keeps individual payloads small enough to embed in tool args, and lets test runs proceed against new tests while patched-original is deferred to SF CLI. Confirmed working in this session: deployed EOIProjectUnitTriggerTest (9KB zip) and TestQuotationClassExtended (35KB zip) via locally-built packages with valid meta.xml. Net result: 16 of 19 tests passing (was 6 of 10), QuotationExtn coverage 0 to 29 percent in one session.

Alternatives Rejected

Outcome

Pending

Graph View

Backlinks