Testing and Validation

Validate your Commerce App before submitting it for review.

Before testing on a sandbox, use the Claude Code skills to catch structural issues early:

  • /validate-app — Comprehensive validation of ZIP structure, manifest, SHA256, IMPEX, icons, and translations
  • /validate-impex — Deep validation of IMPEX XML files for syntax, missing mode="delete" on uninstall, naming conventions, and install/uninstall pairing

These skills catch the most common rejection reasons before you submit.

Before submission, thoroughly test your Commerce App on a sandbox environment:

  • Install via CLI (b2c cap install) to simulate the full installation flow
  • Use b2c cap list --site-id <site-id> to confirm the app appears as installed on the target site
  • Use b2c cap tasks <app-name> --site-id <site-id> to verify configuration task status
  • Verify all configuration tasks complete correctly in Business Manager
  • Verify cartridges appear in the site’s cartridge path after installation
  • For tax apps: verify TaxAppHooksEnabled is automatically enabled after installation
  • Test uninstall and verify clean removal: cartridges removed from path, IMPEX cleanup (services, custom objects)
  • Test re-install after uninstall to verify idempotency
  • Install the app on two different sites within the same realm
  • Uninstall from one site and verify the other site is unaffected (cartridge files remain, feature toggles stay enabled)
  • Uninstall from the last site and verify full cleanup occurs (cartridge files deleted, feature toggles disabled, uninstall IMPEX runs)
  • Test the end-to-end shopper flow on the Storefront Next storefront
  • For backend-only apps (extension points): test with realistic data, error conditions, and edge cases specific to your domain
  • For fullstack apps (custom SCAPI): verify that your components render correctly with data from your SCAPI
  • For UI-only and fullstack apps (Storefront Next extensions): test component rendering across all targeted surfaces, responsive behavior, and accessibility
  • Test on a replicated Production-like instance to validate code and data replication

Your app will be validated against these criteria during review:

  • The app does what it claims to do across all documented features
  • Extension point implementations return valid responses for all contract methods
  • Error states are handled gracefully (timeouts, service unavailability, bad data)
  • CAP structure conforms to the specification (see Architecture Overview)
  • All required files are present and valid
  • IMPEX data is well-formed and uses proper site-scoped patterns
  • No hardcoded site IDs, instance URLs, or credentials in code or IMPEX
  • No exposed credentials or secrets in code or configuration files
  • Proper use of service credentials for external API calls
  • Input validation on all user-supplied data
  • Output encoding to prevent XSS in UI components
  • Extension point implementations respond within acceptable timeouts
  • UI components render efficiently without blocking the main thread
  • No excessive API calls or data fetching
  • README.md provides clear installation and configuration instructions
  • All configuration options are documented
  • Known limitations are disclosed

Known areas of attention:

  • Hardcoded credentials or site-specific values in IMPEX files
  • Missing uninstall IMPEX (cleanup must be as thorough as installation)
  • Extension point implementations that don’t handle error cases
  • Storefront components that break the merchant’s existing layout or styling