Testauksen selkäranka – bisneskriittisten Svelte‑komponenttien varmistaminen AI Commerce Cloudissa

Lue vinkit bisneskriittisten Svelte-komponenttien tehokkaaseen testaukseen ja varmistamiseen AI Commerce Cloudissa.

Updated at April 17th, 2025

+ Lisää

Sisällysluettelo

1. Bisneskriittiset pisteet, jotka aina testataan 2. Tekninen toteutus 2.1 Testauspinon osat 2.2 Periaatteet 3. Esimerkkitesti: “lisää ostoskoriin” 4. SLA ja taloudellinen vastuu 5. Kumppaneille: näin osallistut 6. Yhteenveto

AI Commerce Cloudin lupaus asiakkaille ja partnereille on yksinkertainen: kauppa pysyy pystyssä ja myyntisuppilo toimii. Lupauksen takaamiseksi olemme rakentaneet kattavan testiputken, joka tarkistaa tärkeimmät liiketoimintaprosessit automaattisesti jokaisella deploy‑kierroksella myös frontendin puolella.

Tässä artikkelissa kuvaamme:

Mihin osa‑alueisiin keskitymme (bisneskriittiset komponentit)
Millä työvälineillä ja periaatteilla testit toteutetaan (Svelte + Vitest)
Miten testit integroidaan CI/CD‑putkeen ja SLA‑seurantaan
Kumppaneiden roolin laajentaa testikattavuutta omilla PR‑muutoksilla

1. Bisneskriittiset pisteet, jotka aina testataan

Kategoria	Esimerkkivirhe, johon testi pyrkii tarttumaan
Ostoskori – tuotteen lisääminen	Tuote ei siirry sessioon → asiakas poistuu
Maksutavat ja ‑paluu‑URL	Kaksoisveloitus, väärä status → tuki kuormittuu
Kirjautuminen & tilille luonti	2FA‑tai salasanavirhe estää kassalle pääsyn
Tilauksen luominen	API‑timeout tai puuttuva kenttä estää orderId:n
Checkoutin asiakastiedot	Osoite‑/vero‑säännöt väärin → toimitus hylätään
Tuotesivujen renderöinti	Virheellinen variantti‑ID → tyhjä “add to cart”
Kategoria‑/listanäkymä	Lajitteluvalinta kaataa SSR:n

Nämä testit ajetaan blokkaavina – CI pysähtyy, jos yksikin epäonnistuu.

2. Tekninen toteutus

2.1 Testauspinon osat

Kerros	Työkalu	Käyttö
Unit / render	`@testing-library/svelte` + `Vitest`	Komponenttien DOM‑logiikka & state
Integraatio / stub	sama, mutta mockatut HTTP‑/store‑rajapinnat	AddCart ↔ Cart‑store, PaymentSelector ↔ PSP‑adapteri
Static	ESLint (+ Sveltelint)	Koodistandardit, yleisimmät virheet
E2E (roadmap)	Playwright (headless)	Täysi “kori → maksu → tilaus” selaimessa

2.2 Periaatteet

Jokainen testi eristyy – ulkoiset fetchit korvataan stubilla; vain yksi asia saa mennä verkkoon kerrallaan.

Natiivi Svelte‑store, ei jest.fn()‑subscribeja – vähemmän TDZ‑virheitä ja realistisempi reaktiivisuus.

ASCII‑puhdas testikoodi – Rollup ei kaadu girlandereihin (näistä tuskailimme).

4 välilyöntiä ja anonyymit funktiot – sama tyylisopimus kuin tuotannossa.

3. Esimerkkitesti: “lisää ostoskoriin”

// 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'
    )
})

Testi validoi:

Nappi löytyy ja on klikattavissa
addCart saa täsmälleen oikean objektin
Sessio‑ID (“cart”) välittyy toisena parametrina

4. SLA ja taloudellinen vastuu

Mittari	SLA‑tavoite	Valvontatapa
Checkout‑polun onnistuminen CI:ssä	100.00 %	Pakollinen testi per Git‑commit
Produktioputken regressiot	< 0.01 % / kk	Telemetria + alertit Slackiin
Palautteen korjaus bisneskriittisessä bugin kohdalla	2 h	On‑call rota, hot‑fix branch

Automaatit eivät kata kaikkea → manuaalinen smoke‑testi ennen tuotantoon vientiä on edelleen pakollinen. Kirjaamme Jira‑tikettiin “Go / No Go”.

5. Kumppaneille: näin osallistut

Forkkaa repo, checkout partner-tests branch.
Lisää oma testi tests/<domain>/<feature>.test.js – käytä samaa tekniikkaa kuin esimerkissä.
Aja npm run test. Jos vihreä → tee PR.
Arvostamme unit‑/integraatiotestejä erityisesti seuraaviin:
- Uudet maksutapojen moduulit
- Räätälöidyt kampanjalogiikat
- Asiakasprofiilin laajennuskentät

6. Yhteenveto

Panostamme testikattavuuteen, koska SLA = taloudellinen vastuu.
Keskitymme ensin bisneskriittisiin kohtiin: kori, maksu, kirjautuminen, tilaus, checkout‑formit, renderöinti.
Käytämme Vitest + Svelte Testing Library + ESLint; E2E Playwright laajenee 2025.
Testit ajetaan jokaisessa CI‑rakennuksessa – mutta manuaalinen hyväksyntä säilyy.
Kumppanit voivat (ja toivomme että te) lisäätte testejä – PR + bonus.

Näillä periaatteilla sekä me että integraatiopartnerit voimme luottaa siihen, että AI Commerce Cloud skaalautuu ja pysyy toimintavarmana kovankin liikenteen keskellä.

varmistaminen