Testing Backbone – Ensuring Business-Critical Svelte Components in AI Commerce Cloud
Read tips for effectively testing and validating business-critical Svelte components in AI Commerce Cloud.
AI Commerce Cloud’s promise to customers and partners is simple: your store stays up and your sales funnel works . To back this promise, we’ve built a comprehensive test pipeline that automatically checks key business processes on every deployment round, including on the frontend.
In this article we describe:
- What areas do we focus on (business-critical components)
- What tools and principles are used to implement the tests (Svelte + Vitest)
- How to integrate tests into your CI/CD pipeline and SLA tracking
- The role of partners in expanding test coverage with their own PR changes
1. Business-critical points that are always tested
Category | Example error that the test aims to catch |
---|---|
Shopping cart – adding a product | Product does not transfer to session → customer leaves |
Payment methods and return URL | Double charge, wrong status → support is overloaded |
Login & Account Creation | 2FA or password error prevents access to checkout |
Creating an order | API timeout or missing field prevents orderId |
Checkout customer information | Address/tax rules incorrect → delivery rejected |
Product page rendering | Invalid variant ID → empty “add to cart” |
Category/list view | Sorting selection crashes SSR |
These tests are run in a blocking manner – CI stops if even one fails.
2. Technical implementation
2.1 Components of a testing stack
Layer | Tool | Use |
---|---|---|
Unit / render |
@testing-library/svelte + Vitest
|
DOM logic & state of components |
Integration / stub | same, but mocked HTTP/store interfaces | AddCart ↔ Cart‑store, PaymentSelector ↔ PSP adapter |
Static | ESLint (+ Sveltelint) | Coding standards, most common errors |
E2E (roadmap) | Playwright (headless) | Full “cart → payment → order” in the browser |
2.2 Principles
Each test is isolated – external fetches are replaced with stubs; only one thing is allowed to go online at a time.
Native Svelte store, no jest.fn()
subscriptions – fewer TDZ errors and more realistic responsiveness.
ASCII-pure test code – Rollup doesn't crash on garlands (which is what we were worried about).
4 spaces and anonymous functions – same style convention as in production.
3. Example test: “add to cart”
// tests/cart/add_to_cart.test.js
import { vi, expect, it } from 'vitest'
import { render, fireEvent } from '@testing-library/svelte'
import AddCart from 'src/pages/product/[slug]/AddCart.svelte'
import { addCart } from '$lib/cart'
vi.mock('$lib/cart', () => ({ addCart: vi.fn() }))
it('puskuroi yksinkertaisen tuotteen koriin', async () => {
const { getByText } = render(AddCart, {
props: { updatePrice: () => {}, comment: '' }
})
await fireEvent.click(getByText('Add to Cart'))
expect(addCart).toHaveBeenCalledWith(
{ id: '123', variant: null, quantity: 1 },
'cart'
)
})
The test validates:
- The button is found and clickable.
-
addCart
gets exactly the right object - The session ID (“cart”) is passed as the second parameter
4. SLA and financial responsibility
Meter | SLA target | Control method |
---|---|---|
Checkout Path Success in CI | 100.00 % | Mandatory test per Git commit |
Production pipeline regressions | < 0.01% / month | Telemetry + alerts to Slack |
Feedback correction for a business-critical bug | 2 hours | On‑call rota, hot‑fix branch |
Automation doesn't cover everything → manual smoke testing before production is still mandatory. We will record a “Go / No Go” in the Jira ticket.
5. For partners: how to participate
- Fork repo, Checkout
partner-tests
branch. - Add your own test
tests/<domain>/<feature>.test.js
– use the same technique as in the example. - Run
npm run test
. If green → make a PR. - We especially value unit/integration tests for the following:
- New payment methods modules
- Customized campaign logics
- Customer profile extension fields
6. Summary
- We focus on test coverage because SLA = financial responsibility.
- We will first focus on business-critical areas: cart, payment, login, order, checkout forms, rendering.
- We use Vitest + Svelte Testing Library + ESLint; E2E Playwright expands to 2025.
- Tests are run on every CI build – but manual approval remains.
- Partners can (and we hope you will) add tests – PR + bonus.
With these principles, both we and our integration partners can trust that AI Commerce Cloud will scale and remain reliable even in the midst of heavy traffic.