WordPress unit testing: realistinen testistrategia

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.