Slik kommer du i gang med PHPUnit uten å drukne i oppsett og konfig

Automatiske tester i PHP har rykte på seg for å være mye styr før du i det hele tatt får kjørt din første test. Mange utsetter det, selv om de vet de burde teste mer.

PHPUnit er standardvalget for enhetstester i PHP, men det kan virke tungt å komme i gang. Her får du en praktisk gjennomgang av hvordan du setter opp PHPUnit, lager dine første tester og unngår typiske feller, med fokus på en arbeidsflyt som fungerer i hverdagen.

Hva er PHPUnit, og når gir det mening å bruke det?

PHPUnit er et testverktøy for PHP som lar deg skrive kode som sjekker at annen kode oppfører seg som forventet. Du beskriver forventet resultat i tester, kjører dem ofte, og får rask beskjed når noe går i stykker.

Det passer særlig godt når du har:

• Funksjoner eller klasser med tydelig inn og ut-data (for eksempel services, helpers, repositories).
• Kritisk logikk som ikke må feile (betaling, beregninger, integrasjoner).
• Et kodebase som flere utviklere jobber på samtidig.

For små engangsskript er full testpakke ofte overkill, men med en gang du har et prosjekt som skal vedlikeholdes over tid, er PHPUnit verdt å vurdere.

Enkelt oppsett med Composer

Den enkleste og mest fremtidsvennlige måten å installere PHPUnit på er via Composer. Sørg først for at du har encomposer.jsoni prosjektet ditt. Hvis ikke, kan du lage en tom:

1. Initialiser Composer om nødvendig
Kjør i prosjektmappen:

composer init

Følg veiviseren, eller trykk Enter gjennom det meste og juster senere.

2. Installer PHPUnit som utvikleravhengighet
Kjør:

composer require –dev phpunit/phpunit

Dette legger PHPUnit ivendor/bin/phpunitog oppdaterercomposer.jsonogcomposer.lock. Nå har du alt du trenger for å kjøre tester uten å installere noe globalt på maskinen.

Struktur: hvor skal testene ligge?

En ryddig struktur gjør tester enklere å finne og vedlikeholde. Et vanlig oppsett for et lite eller mellomstort prosjekt er:

• src/for produksjonskode
• tests/for tester

En enkel struktur kan se slik ut:

• src/
  • Calculator.php
• tests/
  • CalculatorTest.php

Navngivingen er viktig: når en klasse heterCalculator, er det naturlig at testklassen heterCalculatorTest. Det gjør det lett å bla mellom filene og er standard i PHPUnit-verdenen.

Lag din første PHPUnit-test

La oss si at du har en veldig enkel klasse isrc/Calculator.php:

Eksempel:

<?php
class Calculator {
  public function add(int $a, int $b): int {
    return $a + $b;
  }
}

Så lager du en testfil itests/CalculatorTest.php:

<?php
use PHPUnitFrameworkTestCase;

class CalculatorTest extends TestCase {
  public function testAddReturnsSum(): void {
    $calculator = new Calculator();
    $result = $calculator->add(2, 3);
    $this->assertSame(5, $result);
  }
}

Nøkkelpunkter her:

• Testklassenarver TestCasefra PHPUnit.
• Testmetoderstarter med “test”og har gjerne beskrivende navn.
• assertSamesjekker at verdien og typen stemmer, ikke bare at de er “like nok”.

Kjør tester via Composer-script

Du kan kjøre testene direkte med:

vendor/bin/phpunit

For å gjøre det kortere og mer likt på tvers av maskiner, er det vanlig å definere et Composer-script icomposer.json:

“scripts”: {
  “test”: “phpunit”
}

Da kan du kjøre:

composer test

Hvis alt er konfigurert riktig, vil du se at PHPUnit finner testfilen, kjører testen og rapporterer grønt. Hvis noe ikke stemmer, får du en feilmelding med hvilken assertion som feilet.

Grunnleggende arbeidsflyt med PHPUnit i hverdagen

Målet er ikke bare å ha tester, men å få en vane som ikke er i veien når du jobber. En enkel rytme kan være:

1. Før du endrer noe kritisk, skriv eller oppdater en liten test.
2. Gjør endringen i koden.
3. Kjørcomposer testlokalt.
4. Fiks feil til testene er grønne.

Over tid kan du innføre mer granulære sjekker, for eksempel bare kjøre tester for én fil med:

vendor/bin/phpunit tests/CalculatorTest.php

eller kjøre tester som matcher et mønster ved hjelp av filter-flagg. Start likevel med full kjøring til du blir komfortabel.

Vanlige feil og enkle måter å unngå dem på

Noen problemer dukker opp igjen og igjen når folk begynner med PHPUnit.

Manglende autoloading
Hvis PHPUnit sier at den ikke finner klassen din, mangler du ofte autoload-oppsett. En enkel løsning er å bruke PSR-4 icomposer.json:

“autoload”: {
  “psr-4”: {
    “App”: “src/”
  }
},
“autoload-dev”: {
  “psr-4”: {
    “Tests”: “tests/”
  }
}

Deretter kjører du:

composer dump-autoload

og sørger for å bruke riktige namespaces i både kildekode og tester.

Tester som er vanskelige å kjøre isolert
Hvis en test er avhengig av database, eksterne API-er eller global state, blir den ofte ustabil. Da er det nyttig å:

• Pakke tilgang til ytre systemer i egne klasser som kan mockes.
• Bruke in-memory databaser der det passer, eller skripter som nullstiller databasen mellom testkjøringer.
• Rydde opp i global state isetUpogtearDownmetoder.

Når du bør konfigurere phpunit.xml

Du kan komme overraskende langt uten enphpunit.xmlhvis prosjektet er lite. Etter hvert som du får flere tester og mapper, er det likevel praktisk med en konfigurasjonsfil i prosjektroten.

En minimal fil kan se slik ut (tilpass etter versjon og behov):

<phpunit bootstrap=”vendor/autoload.php”>
  <testsuites>
    <testsuite name=”Unit”>
      <directory>tests</directory>
    </testsuite>
  </testsuites>
</phpunit>

Da holder det å kjøre:

vendor/bin/phpunit

uten ekstra flagg, og PHPUnit vet hvor testene ligger og hvordan prosjektet skal bootstrappes.

Slik bygger du videre på test-dekningen uten å stoppe utviklingen

Mange forsøker å “fullteste” alt og gir opp når det blir for mye. En mer realistisk strategi er å starte der risikoen er størst og bygge seg utover.

Et par praktiske valg for å komme i gang uten å lamme fremdriften:

• Begynn med nye funksjoner, ikke all gammel kode. Gamle deler kan få tester når de likevel skal endres.
• Prioriter ren logikk fremfor rammeverkslim, for eksempel tjenesteklasser i stedet for route-definisjoner.
• Lag én eller to korte tester for hver kritiske funksjon, i stedet for å sikte mot perfekte scenarier fra start.

Når du har fått inn vanen, kan du vurdere mer avanserte ting som code coverage, integrasjonstester og CI-integrasjon. Men alt dette blir enklere så snart grunnoppsettet med PHPUnit og Composer er på plass.