Rajaa bisneskriittinen käyttäjäpolku

AI Commerce Cloudin Svelte-testauksen lähtökohta on käyttäjälle näkyvä liiketoimintatulos. Nimeä ensin polku, jonka muutos voi estää myynnin tai asioinnin: tuotteen näyttäminen, variantin valinta, ostoskoriin lisääminen, kirjautuminen, toimitus- tai maksutavan valinta, asiakastiedot tai tilauksen valmistuminen.

Kirjaa polulle lähtötila, käyttäjän toiminto, odotettu rajapintakutsu, onnistumistila ja virhetila. Älä nimeä testiä kattavuudeksi koko kassalle, jos se todentaa vain yhden komponentin renderöinnin. Yksikkö- ja integraatiotesti pienentävät regressioriskiä, mutta eivät yksin todista maksupalvelun, backendin, selaimen ja tuotantoympäristön yhteistoimintaa.

Nykyisessä storefront-repossa on testejä esimerkiksi ostoskoriin lisäämiselle, kassamenetelmille, kirjautumiselle, reititykselle, palvelinrenderöinnille ja saavutettavuudelle. Tämä on toteutunut inventaario, ei lupaus siitä, että jokainen maksutapa, paluuosoite, verosääntö tai tilauspolku olisi aina päästä päähän testattu.

Valitse testikerros riskin mukaan

Svelte-komponentin yksikkö- tai renderöintitesti sopii näkyvän tilan, painikkeen, validoinnin ja tapahtuman tarkistamiseen. Store- tai palvelurajan integraatiotesti sopii tilanteeseen, jossa komponentin pitää muodostaa oikea kutsu ja käsitellä vastaus. Saavutettavuustesti tarkistaa rakenteellisia rikkomuksia, mutta ei korvaa näppäimistö- ja ruudunlukijakokeilua.

Staattiset tarkistukset koostuvat nykyisessä storefrontissa ESLintistä ja Svelte Checkistä. Vitest käyttää jsdom-ympäristöä ja Svelte Testing Librarya. Repossa ei ole tällä hetkellä Playwright-riippuvuutta tai Playwright-komentoa, joten täydellistä selainpolkua ei saa merkitä automaattisesti katetuksi.

Valitse mahdollisimman pieni kerros, joka todistaa riskin. Liiketoimintarajaa ylittävä muutos tarvitsee kuitenkin alemman tason testien lisäksi todellisen selaimen smoke-testin hyväksytyssä ympäristössä.

Kirjoita testi todellisen sopimuksen ympärille

Storefrontin testi käyttää Vitestiä, Svelte Testing Librarya ja Svelte-storen oikeaa toteutusta. Valmistele sivu-, istunto-, käännös- ja kauppatila vain testin tarvitsemaan muotoon. Korvaa ulkoinen rajapinta hallitulla testikaksoisella ja palauta jokaisessa testissä vakioitu onnistuminen tai virhe.

Testaa käyttäjän toiminto näkyvän nimen, roolin tai muun vakaan käyttöliittymäsopimuksen kautta. Vältä toteutuksen sisäisen muuttujan tai CSS-rakenteen testaamista, ellei juuri se ole julkaistu sopimus. Tyhjennä kutsuhistoria ennen jokaista testiä, jotta testit eivät riipu suoritusjärjestyksestä.

Pidä ulkoinen verkko poissa yksikkö- ja integraatiotestistä. Testin pitää epäonnistua toistettavasti oman odotuksensa vuoksi, ei kolmannen osapuolen palvelun, verkkoyhteyden tai jaetun ympäristön tilan vuoksi.

Todenna ostoskoriin lisääminen

AI Commerce Cloudin nykyinen ostoskoritesti alustaa yksinkertaisen tuotteen tunnisteellä, tilalla, tyypillä, vähimmäismäärällä, saldoasetuksella, hinnalla ja tyhjillä varianteilla. Testi renderöi ostoskoriin lisäävän komponentin, napsauttaa asiakkaalle näkyvää painiketta ja varmistaa kutsusta vähintään tuotteen tunnisteen, tyhjän variantin ja määrän.

Integraatiotesti varmistaa lisäksi, että toiminto lähettää pyynnön ostoskoripalveluun ja avaa onnistumisen jälkeen ostoskorin. Erilliset testit kattavat valinnaisen custom-option, maarajoituksen ja puuttuvat varianttivalinnat. Kun muutat tätä virtaa, lisää ensin epäonnistuva testi juuri regressiolle ja tee vasta sen jälkeen pienin tuotantokorjaus.

Älä kopioi vanhaa esimerkkitestiä sellaisenaan. Sen komponentin alustustiedot, tuonnit ja odotukset eivät enää vastaa nykyistä testitiedostoa. Käytä saman hakemiston nykyisiä testejä rakenteen mallina ja varmista, että odotus kohdistuu käyttäjälle merkitykselliseen lopputulokseen.

Aja paikalliset portit

AI Commerce Cloudin storefront edellyttää vähintään Node.js-versiota 22. Asenna lukittujen projektitiedostojen mukaiset riippuvuudet ja aja repossa npm run lint, npm test sekä muutoksen toimitustavassa vaadittu build-komento. npm test muodostaa reittikarttojen testiversiot ja ajaa Vitestin kerran.

Lint-komento ajaa ESLintin ilman sallittuja varoituksia sekä Svelte Checkin varoitukset estävin asetuksin. Korjaa virhe juurisyystä; älä ohita testiä, löysennä odotusta tai lisää vaimennusta vain saadaksesi portin vihreäksi.

Kirjaa katselmointiin tarkat komennot, tulokset ja mahdollinen tarkoituksella ajamatta jätetty portti perusteluineen. Vihreä paikallinen ajo ei korvaa riippumatonta katselmointia tai hyväksytyn ympäristön smoke-testiä.

Ymmärrä nykyisen CI-putken raja

AI Commerce Cloudin nykyinen storefront-CI käynnistyy GitHubin push-tapahtumasta, mutta deploy-työ suoritetaan vain, kun commit-viesti sisältää [deploy]. Työ asentaa riippuvuudet, rakentaa asiakasosan ja reittikartat sekä ajaa lintin ja testit ennen palvelinosan rakentamista ja julkaisua. Epäonnistunut lint tai testi estää kyseisen deploy-työn etenemisen.

Työnkulku ei tämän toteutuksen perusteella aja blokkaavia testejä jokaiselle tavalliselle commitille tai pull requestille. Älä siis päättele hyväksymätöntä muutosta turvalliseksi siitä, ettei GitHubissa näy epäonnistunutta deploy-ajoa. Muutoksen tekijä ja katselmoija vastaavat paikallisten porttien todisteesta ennen yhdistämistä.

Älä lisää deploy-tunnistetta pelkkää testiajoa varten. Noudata repossa hyväksyttyä julkaisu- ja tarkastuskäytäntöä sekä varmista ihmisen lupa ennen tuotantoon vaikuttavaa ajoa.

Lisää testi jokaiselle muuttuneelle riskille

AI Commerce Cloudin kumppanimuutos tarvitsee testin, kun se muuttaa Svelte-komponentin tilaa, storea, rajapintakutsua, validointia, maksutapaa, kampanjalogiikkaa tai asiakasprofiilin kenttää. Sijoita testi nykyisen testihakemiston aihejaon mukaiseen paikkaan ja käytä lähimmän toimivan testin asetuksia.

Toimita muutoksen mukana kuvaus riskistä, uusi tai muuttunut testi, porttien tulokset ja smoke-testin tulos. Pyydä omistajalta oikea haara- ja katselmointiohje; nykyisestä reposta ei löydy yleistä partner-tests-haaraa tai kumppanibonuksen sopimusta.

Testikattavuus ei ole prosenttiluku ilman määriteltyä mittaria. Arvioi hyväksyntää sen perusteella, onko muutettu onnistumis-, tyhjä-, lataus- ja virhepolku sekä keskeinen integraatioraja todennettu.

Erota SLA testituloksesta

AI Commerce Cloudin testitulos kertoo vain tarkistetun ohjelmistoehdon onnistumisesta määrätyssä ympäristössä. Se ei itsessään todista tuotannon saatavuutta, regressioprosenttia, korjausaikaa tai palveluhyvitystä. SLA-tavoitteiden pitää tulla hyväksytystä palvelusopimuksesta ja tuotannon mittauksesta.

Älä julkaise testiohjeessa saatavuus-, virheprosentti- tai korjausaikalupausta ilman määritelmää, mittauspistettä, palveluaikaa, poikkeuksia ja sopimusomistajan hyväksyntää. Pidä CI-porttien tekninen tulos, manuaalisen smoke-testin hyväksyntä ja tuotannon SLA-seuranta erillisinä todisteina.

Bisneskriittinen muutos on valmis katselmointiin vasta, kun rajattu riski on testattu oikealla kerroksella, paikalliset portit ovat vihreät, koodi on riippumattomasti arvioitu ja tarvittava smoke-testi on dokumentoitu. Tuotantojulkaisu vaatii lisäksi erillisen luvan.