Salesforce Apex Test Generator Skill

salesforce-apex-test-generator-skill

T0 static code generation for Apex test classes. This skill authors test coverage that is bulkified, assertion-rich, and factory-patterned — the three qualities most often missing from hand-rolled Apex tests. No org connection required.

When This Skill Owns the Task

Use salesforce-apex-test-generator-skill when the work requires authoring new test classes:

• "Write tests for the AccountService class"
• "Generate a @isTest class for my Queueable job"
• "Create test setup data using TestDataFactory"
• "Add positive, negative, and bulk test methods for OrderTriggerHandler"
• "Scaffold an @TestSetup method for the Contact selector tests"
• "Write async test patterns for my batch class"

Delegate elsewhere when:

Required Context to Gather First

Before generating, confirm:

1. Class under test — the production Apex class name and its purpose
2. Class type — service, selector, domain, batch, queueable, schedulable, invocable, REST resource, trigger
3. SObjects involved — what objects the production class creates, reads, or updates
4. TestDataFactory availability — does the project already have a TestDataFactory class? If yes, use it. If no, scaffold a minimal factory or factory pattern.
5. Key behaviors to test — what are the main positive paths, exception paths, and governor-limit edge cases?
6. API version — default 62.0 minimum

If the user provides the production class source, read it to infer what test scenarios are needed. If not, ask for the class name and its purpose.

Recommended Workflow

Step 1 — Read the production class (if available)

Use Read or Grep to locate the class under test. Identify:

• Public methods that need coverage
• Exception paths (try/catch blocks, explicit throws)
• DML operations that need TestDataFactory data
• Async paths (Queueable, Batch, Schedulable enqueue/execute calls)
• callout paths (HTTP callout mocks needed?)

Step 2 — Design test structure

Map each method to test scenarios using the three-path model:

Step 3 — Plan TestDataFactory usage

Consult references/test-data-factory.md. If a project factory exists, extend it. If not, scaffold factory methods as static helpers in the test class or a companion TestDataFactory class.

Step 4 — Author the test class

Follow all hard-stop constraints (see Rules section). Generate:

• @isTest class declaration with private access
• @TestSetup for shared data (when multiple methods need the same records)
• Separate @isTest methods for each positive, negative, and bulk scenario
• Test.startTest / Test.stopTest wrapping all async enqueue or execute calls
• Assert class usage throughout (never bare System.assert)
• No SeeAllData=true unless explicitly required by an external tool pattern

Step 5 — Generate metadata XML

Produce {ClassName}Test.cls-meta.xml with correct apiVersion and status: Active.

Step 6 — Score against the quality rubric

Run the 100-point rubric (see below). If score is below 80, revise before presenting.

Step 7 — Recommend test runner pairing

Always end with an explicit recommendation to execute the tests using salesforce-apex-test-runner-skill, noting the test class name and expected coverage.

Rules

Hard-Stop Constraints (Must Enforce)

Naming Conventions

Quality Scoring Rubric (100-point)

Score the test class before presenting. Threshold: 80+ pass, 60–79 caveat, below 60 revise.

Scoring penalties:

• Missing bulk test: -20
• Bare System.assert without message: -10 per occurrence (max -20)
• SeeAllData=true without justification: -15
• No Test.startTest on async path: -10
• Assertions only on first record in bulk test: -10
• Missing @TestSetup when multiple methods share data setup: -5

T0 Contract

This skill operates exclusively at T0 — static generation only.

• No org connection: No sf CLI calls, no MCP tool calls, no live execution.
• No OAuth required: Zero-scope, zero-credential, zero-network.
• Output is draft code: All generated test classes are starting points for review. Coverage percentages are estimated, not measured. Use salesforce-apex-test-runner-skill for actual execution and coverage measurement.

Refusal Triggers

Stop and do not generate if:

• The user requests SeeAllData=true for a standard use case — explain the isolation risk and generate test-isolated factory data instead. Only emit SeeAllData=true if the user provides a documented reason (e.g., testing a legacy package that requires live data).
• The user requests test methods that assert on hardcoded record Ids — explain the org-portability risk and generate assertions using returned record Ids instead.

Output Format

verdict: "pass | caveat | reject"
quality_score: <0-100>
quality_notes: "<scoring rationale>"

generated_files:
  - path: "{ClassName}Test.cls"
    content: |
      <apex test code>
  - path: "{ClassName}Test.cls-meta.xml"
    content: |
      <meta xml>

test_scenarios_covered:
  positive: ["<method name: scenario description>"]
  negative: ["<method name: scenario description>"]
  bulk: ["<method name: scenario description>"]

factory_approach: "existing-factory | scaffolded-factory | inline-helpers"
factory_notes: "<what factory methods were used or created>"

estimated_coverage_areas:
  - "<class/method: coverage area>"

async_patterns_used: ["Test.startTest/stopTest", "callout mock", "schedulable mock"]

runner_recommendation:
  companion_skill: "salesforce-apex-test-runner-skill"
  test_class: "{ClassName}Test"
  expected_coverage_target: ">=75%"

assumptions:
  - "<list of assumptions made>"

missing_context:
  - "<what the user should provide to improve coverage>"

Handoff Rules

Stop Conditions

Stop and do not continue if:

• The production class under test cannot be located and the user has not provided its source or purpose — ask for the class content or a description of its methods.
• The requested test patterns would require live org data not expressible via factory records — explain the limitation and recommend an approach.

Security Notes

• T0 static generation only: No org connection, no OAuth, no secrets.
• No SeeAllData by default: Test isolation is enforced. Live org data access in tests is a security and reliability anti-pattern.
• No credential generation: Test classes never contain hardcoded credentials, org Ids, or session tokens.
• Factory data only: All test data is generated via factory methods in the test class or TestDataFactory. No reliance on existing org records.

Reference File Index