# Testing and Validation

Validate your Commerce App on a sandbox before you ship it. The install, uninstall, multi-site, and storefront loop in this topic is the SI end-to-end path as well as the ISV pre-submission path.

The [Review Checklist](#review-checklist) and [Common Rejection Reasons](#common-rejection-reasons) apply to **registry submission**. Private apps are not reviewed by the registry team; still follow the same quality bar.

## Validating with Claude Code Skills

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 structural issues before you install or submit.

## Testing Your App

Thoroughly test your Commerce App on a sandbox environment:

### Installation and Uninstallation

- 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
- Verify every prerequisite feature toggle is enabled and the app's hooks execute. Installation doesn't enable prerequisite toggles automatically.
- Test uninstall and verify clean removal: cartridges removed from path, IMPEX cleanup (services, custom objects)
- Test re-install after uninstall to verify idempotency

### Multi-Site Testing

- 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 and hooks continue to execute)
- Uninstall from the last site and verify full cleanup occurs (cartridge files are deleted and uninstall IMPEX runs)

### Functional Testing

- 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

## Review Checklist

For apps submitted to the App Registry, your app is validated against these criteria during review. Private apps skip registry review but should meet the same bar:

### Functional requirements

- 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)

### Packaging requirements

- CAP structure conforms to the specification (see [Architecture Overview](/docs/commerce/b2c-commerce/guide/architecture.md#commerce-app-package-cap-structure))
- 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

### Security requirements

- 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

### Performance requirements

- Extension point implementations respond within acceptable timeouts
- UI components render efficiently without blocking the main thread
- No excessive API calls or data fetching

### Documentation requirements

- README.md provides clear installation and configuration instructions
- All configuration options are documented
- Known limitations are disclosed

## Common Rejection Reasons

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