JavaScripti testimise automatiseerimine: põhjalik juhend pideva integratsiooni seadistamiseks

Kujutage ette sellist stsenaariumi: on hiline tööpäev. Olete just lükanud peamisesse harusse (main branch) midagi, mida peate väikeseks veaparanduseks. Hetk hiljem hakkavad häirekellad tööle. Klienditoe kanalid on üle ujutatud teadetega, et kriitiline, mitteseotud funktsioon on täielikult katki. Järgneb stressirohke ja pingerohke kiirparanduste rabelemine. See olukord, mis on arendusmeeskondadele üle maailma liigagi tavaline, on just see, mida robustne automatiseeritud testimise ja pideva integratsiooni (CI) strateegia on loodud ennetama.

Tänapäeva kiires, globaalses tarkvaraarenduse maastikul ei välista kiirus ja kvaliteet teineteist; nad on vastastikuses sõltuvuses. Võime tarnida usaldusväärseid funktsioone kiiresti on oluline konkurentsieelis. Siin muutub automatiseeritud JavaScripti testimise ja pideva integratsiooni torujuhtmete sünergia kaasaegsete, kõrgjõudlusega insenerimeeskondade nurgakiviks. See juhend on teie põhjalik teekaart CI seadistuse mõistmiseks, rakendamiseks ja optimeerimiseks mis tahes JavaScripti projekti jaoks, olles suunatud globaalsele publikule arendajatest, meeskonnajuhtidest ja DevOps'i inseneridest.

'Miks': CI põhiprintsiipide mõistmine

Enne kui süveneme konfiguratsioonifailidesse ja konkreetsetesse tööriistadesse, on oluline mõista pideva integratsiooni filosoofiat. CI ei ole ainult skriptide käitamine kaugarvutis; see on arenduspraktika ja kultuuriline nihe, mis mõjutab sügavalt seda, kuidas meeskonnad koostööd teevad ja tarkvara tarnivad.

Mis on pidev integratsioon (CI)?

Pidev integratsioon on praktika, kus kõikide arendajate töötavad koodikoopiad liidetakse sageli jagatud peaharuga (mainline) – tihti mitu korda päevas. Iga liitmist ehk 'integratsiooni' kontrollitakse seejärel automaatselt ehituse (build) ja rea automatiseeritud testidega. Esmane eesmärk on tuvastada integratsioonivead nii vara kui võimalik.

Mõelge sellest kui valvsast, automatiseeritud meeskonnaliikmest, kes kontrollib pidevalt, et uued koodipanused ei rikuks olemasolevat rakendust. See vahetu tagasiside ahel on CI süda ja selle kõige võimsam omadus.

CI kasutuselevõtu peamised eelised

• Varajane vigade tuvastamine ja kiirem tagasiside: Iga muudatuse testimisega tabate vead minutite, mitte päevade või nädalatega. See vähendab drastiliselt nende parandamiseks kuluvat aega ja kulusid. Arendajad saavad oma muudatustele kohest tagasisidet, mis võimaldab neil kiiresti ja enesekindlalt itereerida.
• Parem koodikvaliteet: CI torujuhe toimib kvaliteediväravana. See saab jõustada kodeerimisstandardeid linteritega, kontrollida tüübivigu ja tagada, et uus kood on kaetud testidega. Aja jooksul tõstab see süstemaatiliselt kogu koodibaasi kvaliteeti ja hooldatavust.
• Vähem liitmiskonflikte: Integreerides koodi sageli väikeste partiidena, on arendajatel vähem tõenäoline kokku puutuda suurte ja keeruliste liitmiskonfliktidega ('merge hell'). See säästab oluliselt aega ja vähendab vigade tekkimise riski käsitsi liitmiste ajal.
• Suurenenud arendaja produktiivsus ja enesekindlus: Automatiseerimine vabastab arendajad tüütutest, käsitsi testimise ja juurutamise protsessidest. Teadmine, et põhjalik testide komplekt kaitseb koodibaasi, annab arendajatele enesekindluse refaktoreerida, uuendada ja funktsioone tarnida, kartmata regressioonide tekitamist.
• Üks tõe allikas: CI serverist saab lõplik allikas 'rohelise' või 'punase' ehituse jaoks. Kõigil meeskonnaliikmetel, olenemata nende geograafilisest asukohast või ajavööndist, on selge ülevaade rakenduse tervisest igal ajahetkel.

'Mis': JavaScripti testimise maastik

Edukas CI torujuhe on ainult nii hea, kui on testid, mida see käitab. Levinud ja tõhus strateegia testide struktureerimiseks on 'testimise püramiid'. See visualiseerib tervislikku tasakaalu erinevat tüüpi testide vahel.

Kujutage ette püramiidi:

• Alus (suurim ala): Ühiktestid. Need on kiired, arvukad ja kontrollivad teie koodi väikseimaid osi eraldiseisvalt.
• Keskosa: Integratsioonitestid. Need kontrollivad, et mitu ühikut töötavad koos ootuspäraselt.
• Tipp (väikseim ala): Otsast-lõpuni (E2E) testid. Need on aeglasemad ja keerukamad testid, mis simuleerivad reaalse kasutaja teekonda läbi kogu teie rakenduse.

Ühiktestid: Vundament

Ühiktestid keskenduvad ühele funktsioonile, meetodile või komponendile. Need on eraldatud ülejäänud rakendusest, kasutades sageli 'mocke' või 'stub'e' sõltuvuste simuleerimiseks. Nende eesmärk on kontrollida, kas konkreetne loogikajupp töötab erinevate sisendite korral õigesti.

• Eesmärk: Kontrollida individuaalseid loogikaühikuid.
• Kiirus: Äärmiselt kiire (millisekundid testi kohta).
• Peamised tööriistad:
  • Jest: Populaarne kõik-ühes testimisraamistik, millel on sisseehitatud väidete teegid, mockimise võimekused ja koodi katvuse tööriistad. Hooldab Meta.
  • Vitest: Kaasaegne, välkkiire testimisraamistik, mis on loodud sujuvaks koostööks Vite'i ehitustööriistaga, pakkudes Jestiga ühilduvat API-d.
  • Mocha: Väga paindlik ja küps testimisraamistik, mis pakub testidele põhistruktuuri. Seda kasutatakse sageli koos väidete teegiga nagu Chai.

Integratsioonitestid: Ühendav kude

Integratsioonitestid on samm edasi ühikutestidest. Need kontrollivad, kuidas mitu ühikut koostööd teevad. Näiteks esiotsa rakenduses võib integratsioonitest renderdada komponendi, mis sisaldab mitut alamkomponenti, ja kontrollida, kas need suhtlevad õigesti, kui kasutaja klõpsab nupul.

• Eesmärk: Kontrollida moodulite või komponentide vahelisi interaktsioone.
• Kiirus: Aeglasemad kui ühiktestid, kuid kiiremad kui E2E testid.
• Peamised tööriistad:
  • React Testing Library: Mitte testide käivitaja, vaid utiliitide kogum, mis soodustab rakenduse käitumise, mitte implementatsiooni detailide testimist. See töötab koos käivitajatega nagu Jest või Vitest.
  • Supertest: Populaarne teek Node.js HTTP serverite testimiseks, mis teeb selle suurepäraseks API integratsioonitestide jaoks.

Otsast-lõpuni (E2E) testid: Kasutaja vaatenurk

E2E testid automatiseerivad reaalse veebilehitseja, et simuleerida täielikku kasutaja töövoogu. E-poe saidi puhul võib E2E test hõlmata avalehe külastamist, toote otsimist, selle ostukorvi lisamist ja kassaleheleminekut. Need testid pakuvad kõige kõrgemat kindlustunnet, et teie rakendus töötab tervikuna.

• Eesmärk: Kontrollida täielikke kasutajavoogusid algusest lõpuni.
• Kiirus: Kõige aeglasem ja hapram testitüüp.
• Peamised tööriistad:
  • Cypress: Kaasaegne, kõik-ühes E2E testimisraamistik, mis on tuntud oma suurepärase arendajakogemuse, interaktiivse testikäivitaja ja usaldusväärsuse poolest.
  • Playwright: Microsofti võimas raamistik, mis võimaldab brauseriteülest automatiseerimist (Chromium, Firefox, WebKit) ühe API-ga. See on tuntud oma kiiruse ja täiustatud funktsioonide poolest.
  • Selenium WebDriver: Pikaajaline standard brauseri automatiseerimiseks, mis toetab laia valikut keeli ja brausereid. See pakub maksimaalset paindlikkust, kuid selle seadistamine võib olla keerulisem.

Staatiline analüüs: Esimene kaitseliin

Enne kui ühtegi testi isegi käivitatakse, saavad staatilise analüüsi tööriistad tabada levinud vigu ja jõustada koodistiili. Need peaksid alati olema teie CI torujuhtme esimene etapp.

• ESLint: Väga konfigureeritav linter, et leida ja parandada probleeme teie JavaScripti koodis, alates potentsiaalsetest vigadest kuni stiilirikkumisteni.
• Prettier: Arvamusliidrist koodivormindaja, mis tagab ühtse koodistiili kogu teie meeskonnas, kaotades vaidlused vorminduse üle.
• TypeScript: Lisades JavaScriptile staatilised tüübid, suudab TypeScript tabada terve klassi vigu kompileerimise ajal, ammu enne koodi käivitamist.

'Kuidas': Oma CI torujuhtme ehitamine - praktiline juhend

Nüüd lähme praktiliseks. Keskendume CI torujuhtme ehitamisele, kasutades GitHub Actionsit, üht populaarseimat ja kättesaadavamat CI/CD platvormi maailmas. Kontseptsioonid on aga otse ülekantavad teistesse süsteemidesse nagu GitLab CI/CD või Jenkins.

Eeltingimused

1. JavaScripti projekt (Node.js, React, Vue jne).
2. Paigaldatud testimisraamistik (kasutame Jesti ühikutestideks ja Cypressi E2E testideks).
3. Teie kood on hostitud GitHubis.
4. Skriptid on defineeritud teie `package.json` failis.

Tüüpiline `package.json` võib sisaldada selliseid skripte:

`package.json` skriptide näide:

"scripts": {

"start": "react-scripts start",

"build": "react-scripts build",

"lint": "eslint .",

"test": "jest",

"test:ci": "jest --ci --coverage",

"cypress:open": "cypress open",

"cypress:run": "cypress run"

}

Samm 1: Esimese GitHub Actions töövoo seadistamine

GitHub Actions on defineeritud YAML-failides, mis asuvad teie repositooriumi `.github/workflows/` kataloogis. Loome faili nimega `ci.yml`.

Fail: `.github/workflows/ci.yml`

See töövoog käivitab meie linterid ja ühiktestid iga kord, kui kood lükatakse `main` harusse ja iga `main` haru sihtiva pull-requesti puhul.

# See on teie töövoo nimi

name: JavaScript CI

# See jaotis määratleb, millal töövoog käivitub

on:

push:

branches: [ "main" ]

pull_request:

branches: [ "main" ]

# See jaotis määratleb täidetavad tööd

jobs:

# Määratleme ühe töö nimega 'test'

test:

# Virtuaalmasina tüüp, millel töö käivitatakse

runs-on: ubuntu-latest

# Sammud esindavad täidetavate ülesannete jada

steps:

# Samm 1: Laadige alla oma repositooriumi kood

- name: Checkout code

uses: actions/checkout@v4

# Samm 2: Seadistage õige Node.js versioon

- name: Use Node.js 20.x

uses: actions/setup-node@v4

with:

node-version: '20.x'

cache: 'npm' # See lubab npm-i sõltuvuste vahemällu salvestamise

# Samm 3: Paigaldage projekti sõltuvused

- name: Install dependencies

run: npm ci

# Samm 4: Käivitage linter koodistiili kontrollimiseks

- name: Run linter

run: npm run lint

# Samm 5: Käivitage ühiku- ja integratsioonitestid

- name: Run unit tests

run: npm run test:ci

Kui olete selle faili commit'inud ja GitHubi lükanud, on teie CI torujuhe aktiivne! Selle käivitumise nägemiseks navigeerige oma GitHubi repositooriumis vahekaardile 'Actions'.

Samm 2: Otsast-lõpuni testide integreerimine Cypressiga

E2E testid on keerukamad. Nad vajavad töötavat rakendusserverit ja brauserit. Saame oma töövoogu laiendada, et seda käsitleda. Loome E2E testide jaoks eraldi töö, et need saaksid joosta paralleelselt meie ühikutestidega, kiirendades kogu protsessi.

Kasutame ametlikku `cypress-io/github-action`'it, mis lihtsustab paljusid seadistamise samme.

Uuendatud fail: `.github/workflows/ci.yml`

name: JavaScript CI

on:

push:

branches: [ "main" ]

pull_request:

branches: [ "main" ]

jobs:

# Ühikutestide töö jääb samaks

unit-tests:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- uses: actions/setup-node@v4

with:

node-version: '20.x'

cache: 'npm'

- run: npm ci

- run: npm run lint

- run: npm run test:ci

# Lisame uue, paralleelse töö E2E testide jaoks

e2e-tests:

runs-on: ubuntu-latest

# See töö peaks käivituma ainult siis, kui unit-tests töö õnnestub

needs: unit-tests

steps:

- uses: actions/checkout@v4

- uses: actions/setup-node@v4

with:

node-version: '20.x'

cache: 'npm'

- name: Install dependencies

run: npm ci

# Kasutame ametlikku Cypressi actionit

- name: Cypress run

uses: cypress-io/github-action@v6

with:

# Peame rakenduse ehitama enne E2E testide käivitamist

build: npm run build

# Käsk kohaliku serveri käivitamiseks

start: npm start

# Brauser, mida testideks kasutada

browser: chrome

# Oodake, kuni server on sellel URL-il valmis

wait-on: 'http://localhost:3000'

See seadistus loob kaks tööd. Töö `e2e-tests` vajab (`needs`) tööd `unit-tests`, mis tähendab, et see käivitub alles pärast esimese töö edukat lõpuleviimist. See loob järjestikuse torujuhtme, tagades põhilise koodikvaliteedi enne aeglasemate ja kulukamate E2E testide käivitamist.

Alternatiivsed CI/CD platvormid: globaalne perspektiiv

Kuigi GitHub Actions on fantastiline valik, kasutavad paljud organisatsioonid üle maailma teisi võimsaid platvorme. Põhikontseptsioonid on universaalsed.

GitLab CI/CD

GitLabil on sügavalt integreeritud ja võimas CI/CD lahendus. Konfiguratsioon toimub `.gitlab-ci.yml` faili kaudu teie repositooriumi juurkataloogis.

Lihtsustatud `.gitlab-ci.yml` näide:

image: node:20

cache:

paths:

- node_modules/

stages:

- setup

- test

install_dependencies:

stage: setup

script:

- npm ci

run_unit_tests:

stage: test

script:

- npm run test:ci

run_linter:

stage: test

script:

- npm run lint

Jenkins

Jenkins on väga laiendatav, isemajutatav automatiseerimisserver. See on populaarne valik ettevõtluskeskkondades, mis nõuavad maksimaalset kontrolli ja kohandamist. Jenkinsi torujuhtmed on tavaliselt defineeritud `Jenkinsfile`'is.

Lihtsustatud deklaratiivne `Jenkinsfile` näide:

pipeline {

agent any

stages {

stage('Build') {

steps {

sh 'npm ci'

}

}

stage('Test') {

steps {

sh 'npm run lint'

sh 'npm run test:ci'

}

}

}

}

Täiustatud CI strateegiad ja parimad praktikad

Kui teil on põhiline torujuhe töökorras, saate seda optimeerida kiiruse ja tõhususe osas, mis on eriti oluline suurte, hajutatud meeskondade jaoks.

Paralleeliseerimine ja vahemälu kasutamine

Paralleeliseerimine: Suurte testikomplektide puhul võib kõikide testide järjestikune käitamine võtta kaua aega. Enamik E2E testimise tööriistu ja mõned ühikutestide käivitajad toetavad paralleeliseerimist. See hõlmab teie testikomplekti jaotamist mitme virtuaalmasina vahel, mis töötavad samaaegselt. Teenused nagu Cypress Dashboard või CI platvormide sisseehitatud funktsioonid saavad seda hallata, vähendades oluliselt kogu testimisaega.

Vahemälu kasutamine: `node_modules`'i uuesti installimine igal CI käivitamisel on aeganõudev. Kõik suuremad CI platvormid pakuvad mehhanismi nende sõltuvuste vahemällu salvestamiseks. Nagu on näidatud meie GitHub Actionsi näites (`cache: 'npm'`), on esimene käivitamine aeglane, kuid järgnevad on oluliselt kiiremad, kuna nad saavad vahemälu taastada, selle asemel, et kõike uuesti alla laadida.

Koodi katvuse aruandlus

Koodi katvus mõõdab, kui suur osa teie koodist on testidega kaetud. Kuigi 100% katvus ei ole alati praktiline ega kasulik eesmärk, aitab selle mõõdiku jälgimine tuvastada teie rakenduse testimata osi. Tööriistad nagu Jest saavad genereerida katvuse aruandeid. Saate integreerida teenuseid nagu Codecov või Coveralls oma CI torujuhtmega, et jälgida katvust aja jooksul ja isegi ebaõnnestuda ehitust, kui katvus langeb alla teatud künnise.

Näide sammust katvuse üleslaadimiseks Codecovi:

- name: Upload coverage to Codecov

uses: codecov/codecov-action@v4

with:

token: ${{ secrets.CODECOV_TOKEN }}

Saladuste ja keskkonnamuutujate käsitlemine

Teie rakendus vajab tõenäoliselt API-võtmeid, andmebaasi mandaate või muud tundlikku teavet, eriti E2E testide jaoks. Mitte kunagi ärge commit'ige neid otse oma koodi. Iga CI platvorm pakub turvalist viisi saladuste hoidmiseks.

• GitHub Actionsis saate neid hoida `Settings > Secrets and variables > Actions` all. Need on seejärel teie töövoos kättesaadavad `secrets` konteksti kaudu, näiteks `${{ secrets.MY_API_KEY }}`.
• GitLab CI/CD-s hallatakse neid `Settings > CI/CD > Variables` all.
• Jenkinsis saab mandaate hallata selle sisseehitatud Credentials Manageri kaudu.

Tingimuslikud töövood ja optimeerimised

Te ei pea alati igat tööd iga commit'i peale käivitama. Saate oma torujuhet optimeerida, et säästa aega ja ressursse:

• Käivitage kulukaid E2E teste ainult pull-requestide või `main` harusse liitmiste puhul.
• Jätke CI käivitused vahele ainult dokumentatsiooni puudutavate muudatuste puhul, kasutades `paths-ignore`.
• Kasutage maatriksstrateegiaid, et testida oma koodi samaaegselt mitme Node.js versiooni või operatsioonisüsteemi vastu.

CI-st edasi: tee pideva juurutamiseni (CD)

Pidev integratsioon on võrrandi esimene pool. Loomulik järgmine samm on pidev tarnimine (Continuous Delivery) või pidev juurutamine (Continuous Deployment, CD).

• Pidev tarnimine: Pärast kõigi testide edukat läbimist peamises harus, ehitatakse teie rakendus automaatselt ja valmistatakse ette väljalaskeks. Selle tootmisesse juurutamiseks on vaja viimast, käsitsi heakskiitu.
• Pidev juurutamine: See läheb sammu võrra kaugemale. Kui kõik testid läbivad, juurutatakse uus versioon automaatselt tootmisesse ilma inimsekkumiseta.

Saate oma CI töövoogu lisada `deploy` töö, mis käivitub ainult eduka liitmise korral `main` harusse. See töö käivitaks skripte teie rakenduse juurutamiseks platvormidele nagu Vercel, Netlify, AWS, Google Cloud või teie enda serveritesse.

Kontseptuaalne `deploy` töö GitHub Actionsis:

deploy:

needs: [unit-tests, e2e-tests]

runs-on: ubuntu-latest

# Käivita see töö ainult `main` harusse lükkamisel

if: github.ref == 'refs/heads/main' && github.event_name == 'push'

steps:

# ... checkout, setup, build sammud ...

- name: Deploy to Production

run: ./deploy-script.sh # Teie juurutamiskäsk

env:

DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}

Kokkuvõte: kultuuriline nihe, mitte lihtsalt tööriist

CI torujuhtme rakendamine oma JavaScripti projektidele on rohkem kui tehniline ülesanne; see on pühendumus kvaliteedile, kiirusele ja koostööle. See loob kultuuri, kus iga meeskonnaliige, olenemata asukohast, on volitatud panustama enesekindlalt, teades, et paigas on võimas automatiseeritud turvavõrk.

Alustades tugevast automatiseeritud testide vundamendist – alates kiiretest ühikutestidest kuni põhjalike E2E kasutajateekondadeni – ja integreerides need automatiseeritud CI töövoogu, muudate oma arendusprotsessi. Te liigute reaktiivsest vigade parandamise seisundist proaktiivsesse nende ennetamise seisundisse. Tulemuseks on vastupidavam rakendus, produktiivsem arendusmeeskond ja võime pakkuda oma kasutajatele väärtust kiiremini ja usaldusväärsemalt kui kunagi varem.

Kui te pole veel alustanud, tehke seda täna. Alustage väikeselt – võib-olla linteri ja mõne ühikutestiga. Laiendage järk-järgult oma testide katvust ja ehitage oma torujuhet. Esialgne investeering tasub end mitmekordselt ära stabiilsuses, kiiruses ja meelerahus.