dist/codex/salesforce-commerce/skills/sf-testing/SKILL.md
Test Salesforce Commerce code — B2C (Node.js unit testing, sfcc-ci CI/CD, sandbox management, linting) and B2B (Apex test classes with 75% coverage minimum, Jest for LWC, sf CLI deployment and validation). Use when writing tests or setting up CI/CD.
npx skillsauth add orcaqubits/agentic-commerce-claude-plugins sf-testingInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Fetch live docs before writing tests or setting up CI/CD.
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing.htm| Layer | B2C (SFCC) | B2B (Lightning) |
|---|---|---|
| Unit | Mocha/Jest for JS cartridge logic | Apex test classes (@IsTest) |
| Component | N/A | LWC Jest (@salesforce/sfdx-lwc-jest) |
| Integration | SCAPI/OCAPI against sandbox | sf CLI deploy validation |
| E2E | Full checkout flow on sandbox | Full storefront flow on scratch org |
| Linting | ESLint (SFCC config) | ESLint (LWC), Apex PMD |
| Coverage | nyc/istanbul (aim 80%+) | Salesforce enforced minimum 75% |
Unit Testing:
dw.* API stubs (dw.system, dw.catalog, dw.order) via proxyquire or jest.mockIntegration Testing:
Linting and Code Quality:
CI/CD Pipeline (sfcc-ci):
1. sfcc-ci code:deploy -> upload cartridge
2. sfcc-ci code:activate -> activate version
3. npm test -> run unit tests
4. sfcc-ci job:run -> integration tests
Sandbox Management:
| Environment | Purpose | |---|---| | Development | Developer-specific feature work | | Staging | Pre-production validation | | Production | Controlled release deployment |
Apex Test Classes:
@IsTest; minimum 75% coverage enforced by Salesforce@TestSetup for shared test data across methodsSystem.assert(), System.assertEquals(), System.assertNotEquals()Test Data Factory Pattern:
@TestSetup
static void setupTestData() {
// Fetch live docs for TestDataFactory patterns
// Create accounts, products, orders for tests
}
Mock Callouts:
HttpCalloutMock interface for external HTTP calloutsStaticResourceCalloutMock for static response dataTest.setMock()LWC Jest Testing:
@salesforce/sfdx-lwc-jest@wire decorated propertiesjest.mocksf CLI Deployment Validation:
# Dry-run validation with test execution
sf project deploy start --dry-run --test-level RunLocalTests
# Run specific test classes
sf apex run test --class-names MyTestClass --result-format human
Code Coverage Requirements:
| Threshold | Context |
|---|---|
| 75% minimum | Salesforce deployment requirement (org-wide) |
| 85%+ recommended | Critical business logic (payments, orders) |
| 100% target | Apex triggers (keep triggers thin, test all paths) |
| Per-class tracking | sf apex run test --code-coverage reports per class |
B2C Pipeline (GitHub Actions pattern):
| Step | Command |
|---|---|
| Deploy | sfcc-ci code:deploy cartridge.zip -i $SANDBOX |
| Activate | sfcc-ci code:activate --version $VERSION |
| Test | npm test |
B2B Pipeline (Salesforce CLI pattern):
| Step | Command |
|---|---|
| Deploy | sf project deploy start --target-org staging |
| Test | sf apex run test --test-level RunLocalTests --code-coverage |
| Report | sf apex get test --test-run-id $ID |
// Pattern: B2C controller unit test
// Fetch live docs for proxyquire and dw.* mock patterns
// proxyquire('./Controller', {'dw/catalog/ProductMgr': mock})
// assert result matches expected
// Pattern: B2B Apex test with assertions
// Fetch live docs for @IsTest and System.assertEquals
// Test.startTest(); call method; Test.stopTest();
// System.assertEquals(expected, actual, 'message');
dw.* APIs; never rely on live Salesforce APIs in unit testsSystem.runAs() for user context and permission testingFetch the Apex testing guide, LWC Jest documentation, and sfcc-ci CI/CD reference for exact framework versions and configuration before implementing.
development
Build with Spree's headless Next.js storefront — the official `spree/storefront` repo (Next.js 16 App Router with Server Actions and Turbopack, React 19 Server Components, Tailwind CSS 4, TypeScript 5, `@spree/sdk`, Sentry), server-only auth (httpOnly JWT cookies + publishable key), MeiliSearch faceted catalog, one-page checkout with Apple/Google Pay/Klarna/Affirm/SEPA, multi-region market routing, GA4 + JSON-LD SEO, and Vercel/Docker deployment. Use when forking or customizing the storefront, or evaluating headless adoption.
tools
Build Spree extensions as Rails engines — gem scaffolding, `bin/rails g spree:extension`, mounting routes/migrations/assets, the modern `prepend` decorator pattern (`*_decorator.rb` with `self.prepended(base)`), generators (`spree:model_decorator`, `spree:controller_decorator`), the four customization surfaces in preference order (Events > Webhooks > Dependencies > Decorators), Spree::Dependencies for swapping service objects, gem release/versioning, and the deprecated Deface engine. Use when building a reusable Spree extension or adding non-trivial customization to an app.
development
Build with Spree's event bus and Webhooks 2.0 — `Spree::Events` publication, `Spree::Subscriber` DSL with `subscribes_to` and `on`, wildcard matching, lifecycle events (`{model}.created/.updated/.deleted` via `publishes_lifecycle_events`), the canonical event catalog (order.*, payment.*, shipment.*, product.*), Webhooks 2.0 endpoints, HMAC-SHA256 signing (`X-Spree-Webhook-Signature`), exponential-backoff retries, and Sidekiq job orchestration. Use when wiring event-driven business logic, building webhook consumers, or replacing ActiveSupport callback chains.
tools
Cross-cutting Spree development patterns — the customization preference hierarchy (Events > Webhooks > Dependencies > Decorators), `Spree::Dependencies` service-object swapping, the `_decorator.rb` + `prepend` + `self.prepended` idiom, idempotent subscribers and webhook receivers, multi-store scoping discipline, prefixed IDs, calculator polymorphism (shipping/promotion/tax share the base), service-object composition with `dry-monads` or simple results, why to avoid `class_eval` reopening and Deface, and Spree-on-Rails idioms (Hotwire/Turbo Stimulus, ActiveStorage, Action Cable, Sidekiq). Use when designing the architecture of a Spree extension or solving cross-cutting concerns.