Unit testing kuulostaa teoriassa yksinkertaiselta. Kirjoita testejä. Aja testejä. Vältä bugeja. Käytännössä WordPress-maailmassa testaus on kaikkea muuta kuin triviaalista. WordPress ei ole pieni, kapseloitu sovellus. Se on valtava, tilallinen, hook-pohjainen runtime-ekosysteemi.
Ja juuri tästä syystä WordPress-testauksessa realismi on tärkeämpää kuin dogma.
Testaus ei ole ideologinen harjoitus. Se on riskienhallintaa.
Miksi WordPress-testauksessa tulee helposti turhautuminen?
Modernit testausopit syntyivät maailmassa, jossa:
-
riippuvuudet injektoidaan
-
komponentit kapseloidaan
-
globaalia tilaa vältetään
-
sivuvaikutukset minimoidaan
WordPress toimii eri logiikalla:
-
globaali tila on keskeinen
-
hookit ohjaavat logiikkaa
-
runtime on tilallinen
-
suuri osa logiikasta on implisiittistä
Kun nämä maailmat törmäävät, syntyy klassinen kehittäjäkokemus:
“Unit testing WordPressissä tuntuu vaikealta.”
Se ei ole sattumaa. Se on arkkitehtuurinen realiteetti.
Unit testing vs WordPressin todellisuus
Perinteinen unit test -idea:
Testaa yksi pieni yksikkö täydellisessä eristyksessä.
WordPressissä täydellinen eristys on usein illuusio.
Funktio voi:
-
käyttää globaalia $wpdb:tä
-
lukea option
-
luottaa hookiin
-
olettaa query-tilan
Testattava “yksikkö” ei olekaan yksikkö. Se on verkosto.
Tästä syystä realistinen testistrategia ei yritä väkisin sovittaa WordPressiä laboratorio-ihanteeseen.
Se mukautuu runtime’n luonteeseen.
Realistinen lähtökohta: mitä testaus oikeasti suojaa?
Testauksen tarkoitus ei ole maksimoida testikattavuutta.
Se on minimoida riskit.
WordPress-projektissa kriittisiä riskejä ovat usein:
-
regressiot
-
logiikkavirheet
-
edge caset
-
integraatiovirheet
-
tietokantakäyttäytyminen
-
hook-sivuvaikutukset
Kaikkea ei tarvitse testata.
Mutta väärät asiat testattuna ovat yhtä hyödyttömiä kuin ei testejä lainkaan.
Testauksen kerrokset WordPressissä
Realistinen WordPress-testistrategia käyttää useita tasoja.
Unit testit
Hyviä kun:
-
logiikka on puhdasta
-
ei riippuvuuksia WordPress-runtimeen
-
ei globaalia tilaa
-
ei tietokantaa
Esimerkiksi:
-
apufunktiot
-
laskennallinen logiikka
-
datamuunnokset
-
validatorit
Unit testit loistavat deterministisessä logiikassa.
Integration testit
WordPressissä usein tärkeämpiä kuin puhtaat unit testit.
Hyviä kun:
-
logiikka käyttää WP_Queryä
-
logiikka käyttää tietokantaa
-
hookit vaikuttavat
-
globaalit muuttujat mukana
Integration test kysyy:
“Toimiiko tämä oikeassa runtime’ssa?”
Ja WordPress on runtime-first -järjestelmä.
End-to-end testit
Korkeamman tason validointi.
Hyviä kun:
-
UI-logiikka kriittinen
-
käyttäjäpolut tärkeitä
-
JavaScript mukana
-
REST / AJAX mukana
E2E-testit suojaavat käyttäjäkokemusta.
Unit testing WordPressissä: missä se toimii parhaiten?
WordPressissä unit testing toimii loistavasti, kun logiikka irrotetaan WordPressistä.
Tämä ei ole vain testausstrategia.
Se on arkkitehtuuristrategia.
Pure functions = testattavuuden paratiisi
Kun logiikka:
-
ei käytä globaalia tilaa
-
ei käytä WordPress API:a
-
ei tee IO:ta
-
ei tee queryjä
testit ovat:
-
nopeita
-
vakaita
-
deterministisiä
WordPress-projekti hyötyy valtavasti, kun osa logiikasta elää WordPress-runtime’n ulkopuolella.
Mocking WordPressissä: realismi vs fantasia
Mocking on modernin testauksen keskeinen työkalu.
WordPressissä mocking voi olla:
-
hyödyllistä
-
mutta helposti ylilyövää
Jos mockaat liikaa:
-
testaat mockeja, et logiikkaa
-
runtime-käyttäytyminen katoaa
-
emergentit bugit jäävät piiloon
Realistinen strategia:
Mockaa reunat, älä universumia.
Globaali tila ja testaus
Globaalit muuttujat tekevät testauksesta mielenkiintoista.
Testi voi vaikuttaa:
-
seuraavaan testiin
-
runtime-tilaan
-
hook-järjestelmään
Tästä syystä WordPress-testauksessa resetointi on kriittistä.
Testit eivät ole vain validointia.
Ne ovat tilanhallintaa.
Testauksen kustannus: miksi kaikkea ei kannata testata?
Testit eivät ole ilmaisia.
Ne maksavat:
-
aikaa
-
ylläpitoa
-
refaktorointikustannuksia
-
kitkaa kehityksessä
Huono testistrategia:
-
maksimoidaan kattavuus
-
minimoidaan hyöty
Hyvä testistrategia:
-
maksimoidaan riskisuojaus
-
minimoidaan ylläpitokustannus
WordPress ja regressiot: testauksen todellinen supervoima
WordPress-projektit kärsivät harvoin “täysin uusista virheistä”.
Ne kärsivät regressioista.
Jokin, joka toimi ennen → ei toimi enää.
Testaus loistaa juuri tässä.
Testit ovat muistijärjestelmä.
Ne muistavat käyttäytymisen, vaikka kehittäjä ei.
Edge caset: missä testit maksavat itsensä takaisin
Testit ovat erityisen arvokkaita, kun logiikka sisältää:
-
monimutkaista ehtologiikkaa
-
datanormalisointia
-
virheenkäsittelyä
-
fallback-polkuja
Edge caset ovat bugien luonnollinen elinympäristö.
Ja testit ovat niiden luonnollinen torjuntamekanismi.
WordPress runtime -testaus: miksi integration testit ovat usein tärkeimpiä?
WordPress ei ole puhtaasti funktionaalinen järjestelmä.
Se on runtime-ekosysteemi:
-
hookit
-
globaalit muuttujat
-
tietokanta
-
query-logiikka
Integration testit validoivat tämän todellisuuden.
Unit test:
“Toimiiko tämä funktio?”
Integration test:
“Toimiiko tämä WordPressissä?”
Usein jälkimmäinen on tärkeämpi.
Testattavuus = arkkitehtuurin sivutuote
Testattavuus ei synny testejä kirjoittamalla.
Se syntyy arkkitehtuurista.
Kun logiikka:
-
kapseloidaan
-
erotetaan sivuvaikutuksista
-
minimoidaan globaali tila
-
erotetaan IO-logiikka
testaus muuttuu helpoksi.
Hyvä arkkitehtuuri tekee testauksesta halpaa.
Huono arkkitehtuuri tekee testauksesta kivuliasta.
Realistinen WordPress-testistrategia
Realismi tarkoittaa:
-
ei dogmaattista kattavuuspakkoa
-
ei over-mockausta
-
ei laboratorion ihannearkkitehtuurin pakottamista
Sen sijaan:
-
testaa kriittinen logiikka
-
testaa regressioherkät kohdat
-
testaa kompleksiset säännöt
-
testaa integraatiopinnat
-
hyväksy runtime’n luonne
Testaus ei ole täydellisyyttä.
Se on riskienhallintaa.
Filosofinen ydin
Testit eivät ole vain bugien estämistä.
Ne ovat dokumentaatiota.
Ne kuvaavat:
“Miten järjestelmän kuuluu käyttäytyä.”
WordPress-ekosysteemissä tämä on erityisen arvokasta, koska runtime on dynaaminen, laajennettava ja emergentti.
Testit ankkuroivat käyttäytymisen.
Ne tekevät näkymättömästä eksplisiittistä.
Lopuksi: hyvä testistrategia on pragmaattinen
Hyvä WordPress-testistrategia ei ole:
“Kirjoitetaan testejä, koska testaus on hyve.”
Hyvä strategia on:
“Kirjoitetaan testejä, koska tietyt riskit ovat todellisia.”
Testaus ei ole ideologia.
Se on insinöörityökalu.
Ja kuten kaikkien työkalujen kanssa, arvo syntyy siitä, että sitä käytetään oikeaan ongelmaan oikeassa kontekstissa.
