Mocking on yksi modernin testauksen rakastetuimmista konsepteista. Ajatus on elegantti: eristetään testattava logiikka, korvataan riippuvuudet simuloiduilla versioilla, ja testataan käyttäytymistä kontrolloidussa ympäristössä.
Teoriassa täydellistä.
WordPressissä… mielenkiintoista.
Mocking WordPressissä ei ole pelkkä tekninen valinta. Se on törmäys kahden eri arkkitehtuurifilosofian välillä. Moderni testaus suosii kapselointia ja eksplisiittisiä riippuvuuksia. WordPress suosii globaalia tilaa, hook-järjestelmää ja runtime-kontekstia.
Ja juuri tässä syntyvät testauksen epämukavat realiteetit.
Miksi mocking tuntuu luonnolliselta modernissa testauksessa?
Mocking syntyi maailmassa, jossa sovellukset ovat:
-
modulaarisia
-
kapseloituja
-
dependency-injection -pohjaisia
-
eksplisiittisiä rajapinnoiltaan
Kun riippuvuudet ovat selkeitä, ne voidaan korvata.
Mock on vain vaihtoehtoinen toteutus.
WordPress ei ole rakennettu tällä oletuksella.
WordPress runtime: mocking-paradoksin ydin
WordPress ei ole kirjasto, jota kutsutaan.
Se on runtime, joka ladataan.
Kun koodi suoritetaan, mukana ovat:
-
globaalit muuttujat
-
hookit
-
sisäinen tila
-
tietokanta
-
core-logiikka
Mocking kysyy:
“Voimmeko teeskennellä tämän kaiken?”
Teknisesti kyllä.
Käytännössä usein kyseenalaista.
Globaali tila: mockingin luonnollinen vihollinen
Moderni mocking perustuu ajatukseen:
Riippuvuudet ovat parametrisoituja.
WordPressissä riippuvuudet ovat usein:
global $wpdb;
Tämä ei ole injektoitava riippuvuus. Tämä on globaali todellisuus.
Mocking globaalia tilaa tarkoittaa käytännössä:
-
runtime’n manipulointia
-
state’n uudelleenrakennusta
-
epävakaata testausympäristöä
Globaalit muuttujat eivät ole vain dataa.
Ne ovat järjestelmän tilaa.
Hooks: emergenssin mocking-ongelma
Hook-järjestelmä tekee WordPressistä dynaamisen.
Mutta mockingin näkökulmasta hookit ovat painajainen.
Jos mockaat liikaa:
-
hook-ekosysteemi katoaa
-
runtime-käyttäytyminen katoaa
-
emergentit bugit katoavat
Testi näyttää vakaalta.
Tuotanto ei ole.
Klassinen mocking-illuusio
Mockattu funktio:
-
palauttaa täydellisen datan
-
ei sisällä sivuvaikutuksia
-
ei sisällä runtime-kontekstia
Todellinen WordPress:
-
filterit muuttavat dataa
-
hookit vaikuttavat logiikkaan
-
globaalit muuttujat mukana
Testi ei enää mallinna todellisuutta.
Over-mocking: testauksen yleisin ansa
Mocking ei ole ongelma.
Over-mocking on.
Kun testit:
-
mockaavat WordPress corea
-
mockaavat WP_Queryä
-
mockaavat hookit
-
mockaavat tietokannan
testit alkavat validoida simulaatiota.
Ei järjestelmää.
Mocking voi helposti muuttua vaihtoehtoisen universumin rakentamiseksi.
Ja tämä universumi on harvoin sama kuin tuotanto.
WordPress ei ole dependency-injection -framework
Mocking toimii parhaiten, kun riippuvuudet ovat eksplisiittisiä.
WordPress ei ole rakennettu DI-mallille.
Se on rakennettu:
-
globaaleille funktioille
-
globaalille tilalle
-
runtime-kontekstille
Mocking WordPressissä vaatii usein arkkitehtuurin uudelleenajattelua.
Ja tämä ei ole huono asia.
Testattavuus arkkitehtuurin sivutuotteena
Ironinen paradoksi:
Paras tapa tehdä WordPressistä mock-friendly ei ole mockata enemmän.
Se on kirjoittaa vähemmän WordPress-riippuvaista logiikkaa.
Kun logiikka:
-
erotetaan WordPress API:sta
-
kapseloidaan
-
minimoidaan globaalit viittaukset
mocking muuttuu triviaaliksi.
Pure PHP-logiikka = mocking-paratiisi.
Mocking reunalla vs mocking ytimessä
Realistinen WordPress-testistrategia käyttää mockingia selektiivisesti.
Mockataan:
-
ulkoiset API:t
-
HTTP-kutsut
-
maksupalvelut
-
kolmannen osapuolen integraatiot
Ei mockata:
-
WordPress core-logiikkaa
-
query-järjestelmää
-
hook-ekosysteemiä
Muuten realismi katoaa.
Mocking vs integration testing
Mocking ja integration testing eivät ole kilpailijoita.
Ne ovat työkaluja eri ongelmiin.
Mocking:
-
nopea
-
kontrolloitu
-
mutta usein irrotettu runtime’sta
Integration testing:
-
hitaampi
-
realistisempi
-
paljastaa emergenssin
WordPressissä integration testing on usein arvokkaampi.
Ei siksi, että mocking olisi väärin.
Vaan siksi, että runtime on keskeinen.
Epämukava totuus: täydellinen eristys ei aina ole hyödyllistä
Moderni testausideologia suosii täydellistä eristystä.
WordPressissä täydellinen eristys voi johtaa:
-
harhaanjohtaviin testeihin
-
väärään turvallisuuden tunteeseen
-
runtime-bugien näkymättömyyteen
Jos tuotantobugi syntyy hook-interaktiosta, mockattu unit test ei näe sitä.
Integration test näkee.
Emergentit bugit ja mockingin rajat
WordPress-ekosysteemissä moni bugi on emergentti:
-
pluginien välinen interaktio
-
hookien välinen interaktio
-
queryjen sivuvaikutukset
Mocking ei mallinna emergenssiä hyvin.
Se mallintaa kontrolloitua käyttäytymistä.
Ja WordPress ei ole täysin kontrolloitu ympäristö.
Mocking ei ole vihollinen
Mocking on erinomainen työkalu:
-
puhtaalle logiikalle
-
IO-riippuvuuksille
-
ulkoisille järjestelmille
-
deterministisille komponenteille
Ongelma ei ole mocking.
Ongelma on väärä odotus siitä, mitä mocking voi realistisesti mallintaa WordPressissä.
Realistinen strategia
Kypsä WordPress-kehittäjä ei kysy:
“Kuinka paljon voimme mockata?”
Kypsä kehittäjä kysyy:
“Missä mocking lisää signaalia ja missä se lisää kohinaa?”
Testauksen tarkoitus ei ole rakentaa täydellistä simulaatiota.
Se on paljastaa riskit.
Filosofinen ydin
Mocking edustaa ajatusta kontrolloidusta todellisuudesta.
WordPress edustaa emergenttiä runtime-todellisuutta.
Näiden välinen jännite ei ole virhe.
Se on luonnollinen seuraus järjestelmän arkkitehtuurista.
Hyvä testausstrategia ei yritä pakottaa WordPressiä laboratorioon.
Se hyväksyy runtime’n luonteen ja käyttää mockingia siellä, missä se oikeasti tuo arvoa.
Lopuksi: realismi voittaa dogman
Mocking ei ole hyve.
Integration testing ei ole hyve.
Ne ovat työkaluja.
WordPress-testauksessa realismi on tärkein periaate.
Testi, joka ei mallinna todellisuutta, ei ole testaus.
Se on vaihtoehtoisen universumin dokumentointi.
Ja tuotanto ei elä siinä universumissa.
