Integration testing on se testauksen alue, jossa teoriakirjat ja WordPressin todellisuus vihdoin kättelevät toisiaan. Unit testingissä tavoitteena on täydellinen eristys. Integration testingissä hyväksytään, että maailma on monimutkainen, tilallinen ja täynnä riippuvuuksia.
Ja WordPress jos mikä on riippuvuuksien ekosysteemi.
Core. Pluginit. Teemat. Hookit. Globaali tila. Tietokanta. REST. Ajax. Välimuistit.
Täydellinen laboratorioeristys ei ole WordPressissä vain vaikeaa. Se on usein epärealistista.
Integration testing ei ole WordPressissä kompromissi.
Se on realismia.
Mitä integration testing oikeastaan tarkoittaa?
Integration test kysyy yksinkertaisen mutta syvällisen kysymyksen:
“Toimivatko nämä komponentit yhdessä?”
Ei enää:
“Toimiiko tämä funktio?”
Vaan:
-
Toimiiko tämä logiikka WordPress-runtime’ssa?
-
Toimiiko tämä WP_Queryn kanssa?
-
Toimiiko tämä tietokannan kanssa?
-
Toimiiko tämä hook-järjestelmän kanssa?
WordPressissä juuri nämä kysymykset ovat usein kriittisimpiä.
WordPress runtime: integration testingin luonnollinen pelikenttä
WordPress ei ole staattinen kirjasto. Se on runtime-ympäristö.
Kun koodi suoritetaan, mukana ovat:
-
globaali tila
-
hookit
-
tietokanta
-
sisäinen state machine
Moni bugi ei synny yksittäisessä funktiossa.
Se syntyy interaktioissa.
Integration testing on juuri tätä varten.
Unit testing vs integration testing WordPressissä
Unit test:
-
nopea
-
deterministinen
-
mutta usein irrotettu todellisuudesta
Integration test:
-
hitaampi
-
raskaampi
-
mutta paljon lähempänä tuotantokäyttäytymistä
WordPressissä integration testit ovat usein arvokkaampia, koska runtime on niin keskeinen osa logiikkaa.
Klassinen WordPress-bugi
Logiikka toimii unit testissä.
Tuotannossa:
-
hook muuttaa queryä
-
plugin lisää filterin
-
globaali tila muuttuu
Käyttäytyminen hajoaa.
Unit test ei nähnyt tätä.
Integration test olisi nähnyt.
Tietokanta: WordPress-logiikan keskipiste
WordPress ei ole vain PHP-sovellus. Se on tietokantavetoinen järjestelmä.
Moni kriittinen logiikka liittyy:
-
WP_Queryyn
-
meta-dataan
-
taxonomyihin
-
option-rakenteisiin
Tietokantaa mockaamalla voidaan testata logiikkaa.
Tietokantaa käyttämällä voidaan testata todellisuutta.
Integration testing suosii jälkimmäistä.
Hooks: emergenssin ydin
WordPressin hook-järjestelmä tekee integration testingistä lähes välttämättömän.
Hookit:
-
muuttavat dataa
-
muuttavat suoritusjärjestystä
-
muuttavat logiikkaa
Unit testissä hookit usein puuttuvat.
Runtime’ssa ne ovat kaikkialla.
Integration test validoi hook-ekosysteemin vaikutukset.
Globaali tila ja tilallinen käyttäytyminen
WordPress runtime sisältää:
-
globaalit muuttujat
-
query-tilan
-
sisäiset objektirakenteet
Integration test voi validoida:
-
oikean state transitionin
-
oikean resetoinnin
-
oikean käyttäytymisen useiden komponenttien välillä
WordPressissä state bugs ovat yleisiä.
Integration testit ovat niiden luonnollinen torjuntatyökalu.
Realistinen testausympäristö
Integration testing WordPressissä tarkoittaa käytännössä:
-
WordPress asennettuna
-
testitietokanta
-
runtime ladattuna
-
core-logiikka aktiivisena
Tämä ei ole “raskas vaihtoehto”.
Tämä on realistinen vaihtoehto.
Miksi tämä on tärkeää?
Koska WordPress-koodi harvoin elää tyhjiössä.
Se elää runtime’ssa.
Testauksen kustannus vs hyöty
Integration testit ovat:
-
hitaampia kuin unit testit
-
monimutkaisempia
-
vaativat enemmän setupia
Mutta ne löytävät:
-
runtime-virheitä
-
query-ongelmia
-
hook-konflikteja
-
state-ongelmia
Kustannus kasvaa.
Mutta niin kasvaa hyöty.
Milloin integration testing on erityisen arvokasta?
Kun logiikka sisältää:
-
WP_Queryä
-
tietokantamuutoksia
-
hook-manipulaatioita
-
REST-logiikkaa
-
meta_queryä
-
tax_queryä
Näissä tapauksissa unit test voi testata logiikkaa.
Integration test testaa järjestelmää.
Ja WordPress on järjestelmä.
Regressiot ja integration testing
WordPress-ekosysteemi on dynaaminen.
-
pluginit päivittyvät
-
core päivittyy
-
PHP päivittyy
Integration testit toimivat regressiosuojana runtime-tasolla.
Ne eivät vain validoi logiikkaa.
Ne validoivat käyttäytymistä ympäristössä.
Emergentit bugit: WordPressin erikoisuus
WordPressissä moni bugi on emergentti.
Ei yksittäinen virhe, vaan:
-
pluginien interaktio
-
hookien interaktio
-
queryjen interaktio
Integration testing on lähes ainoa tapa havaita nämä systemaattisesti.
Unit test ei näe ekosysteemiä.
Integration test näkee.
Mocking integration testingissä
Mocking ei katoa integration testingissä.
Mutta sen rooli muuttuu.
Mockataan:
-
ulkoiset API:t
-
verkko
-
kolmannen osapuolen palvelut
Ei mockata:
-
WordPress corea
-
tietokantaa
-
hook-järjestelmää
Muuten realismi katoaa.
Testien vakaus: flakinessin ikuinen vihollinen
Integration testit voivat olla alttiita flakinessille:
-
tilariippuvuudet
-
data-riippuvuudet
-
ajalliset riippuvuudet
Tästä syystä resetointi ja determinismi ovat kriittisiä.
Testit eivät saa olla:
“Ehkä toimii.”
Testien on oltava:
“Toimii aina tai ei koskaan.”
WordPress ja testattavuuden filosofia
Integration testing heijastaa syvempää ajattelumallia.
WordPress ei ole vain koodia.
Se on runtime-käyttäytymistä.
Testaus ei suojaa vain funktioita.
Se suojaa interaktioita.
Ja WordPressissä interaktiot ovat kaikki.
Realistinen WordPress-testistrategia
Kypsä strategia:
-
unit testit puhtaalle logiikalle
-
integration testit runtime-logiikalle
-
E2E-testit käyttäjäpoluille
Ei dogmaattista yhtä mallia.
Vaan kerroksellinen realismi.
Filosofinen ydin
Integration testing hyväksyy yhden ohjelmistokehityksen perusrealiteetin:
Suurin osa virheistä ei synny yksiköissä.
Ne syntyvät rajapinnoissa.
WordPress on rajapintojen järjestelmä:
-
PHP ↔ tietokanta
-
plugin ↔ core
-
hook ↔ runtime
-
query ↔ data
Integration testit valaisevat juuri nämä rajapinnat.
Lopuksi: integration testing ei ole “raskaampi unit testing”
Se on eri ajattelumalli.
Unit test kysyy:
“Toimiiko tämä logiikka eristyksessä?”
Integration test kysyy:
“Toimiiko tämä logiikka todellisuudessa?”
WordPress-kehityksessä jälkimmäinen kysymys on usein se, jolla on eniten merkitystä.
Koska lopulta tuotantoympäristö ei ole eristetty.
Se on WordPress.
