Kirjoitusyksikkötestit PHPUnitilla, Osa 3: XML-kokoonpano

Viimeisin päivitys marras 29, 2022

Sisältö

PHPUnit XML -kokoonpano

1 Tiedostojen poistaminen

2 Määritystiedoston perusteet

3 Bootstrap-tiedosto

4 Perustesti, hylätty

4 Muutama perustesti, läpäisevä testi

Onko enemmän? (Aina oikeassa?)

Tämän sarjan aiemmissa viesteissä olen käsitellyt seuraavia kahta aihetta:

Kirjoitusyksikkötestit PHPUnitilla, Osa 1: Asennus. Opas PHPUnit-testien kirjoittamisen aloittamiseen perusvälimuistin ja kehyksen setUp-menetelmän avulla.
Kirjoitusyksikkötestit PHPUnitilla, Osa 2: Tear Down. Opetusohjelma yksikkötestien kirjoittamisesta, jotka hyödyntävät oikein PHPUnitin setUp- ja tearDown-menetelmiä.

Jokainen yllä olevista on tarkoitettu antamaan alulle, kuinka aloittaa hyvin perusyksikkötestien kirjoittaminen. Asiat voivat muuttua monimutkaisemmiksi varsinkin sovelluksen tai projektin kasvaessa (mutta se on aina totta, eikö?).

Mutta varmistaaksemme, että ihminen on valmistautunut siihen, yksikkötestauksessa on yksi viimeinen komponentti, johon meidän pitäisi mielestäni keskittyä, ja se on PHPUnit XML -määritystiedoston ymmärtäminen (jonka olet ehkä nähnyt muissa projekteissa nimellä phpunit.xml).

PHPUnit XML -kokoonpano

Joten tässä viestissä aion perustaa yksinkertaisen projektin, joka käyttää PHPUnit-yksikköä, kirjoittaa muutamia testejä, kuten olemme jo nähneet, ja hyödyntää määritystiedostoa testauksen automatisoimiseksi.

Lisäksi aion tehdä parhaani selittääkseni määritystiedoston tarvittavat osat, jotta voit sisällyttää sellaisen seuraavaan projektiisi.

1 Tiedostojen poistaminen

Ennen kuin aloitat testattavan koodin kirjoittamisen, on tärkeää tietää tiedostot, joita tarvitaan prosessin toimimiseen.

Seuraavassa on enemmän tai vähemmän, kuinka järjestämme asiat projektin alusta alkaen:

testihakemisto,
phpunit.xml – tiedosto

Lopulta näet myös:

tiedostot, jotka muodostavat projektin,
testit, jotka vahvistavat mainitut tiedostot.

Tässä vaiheessa katsotaan kuitenkin XML-määritystiedostoa ja yritetään sitten suorittaa PHPUnit automaattisesti ilman muita parametreja.

2 Määritystiedoston perusteet

Katsotaanpa ensin perusasetustiedostoa:

<?xml version="1.0" encoding="UTF-8"?>

<!-- http://phpunit.de/manual/4.1/en/appendixes.configuration.html -->
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="http://schema.phpunit.de/4.1/phpunit.xsd"
         bootstrap="./tests/bootstrap.php"
         backupGlobals="false"
         colors="true"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
>
  <testsuites>
    <testsuite name="AcmeTests">
      <directory>./tests</directory>
    </testsuite>
  </testsuites>

  <logging>
    <log type="coverage-text" target="php://stdout" showUncoveredFiles="true"></log>
  </logging>
</phpunit>

Ymmärrämme nyt, mitä tarkalleen tarkastelemme (muuta kuin yksinkertaista XML:ää).

phpunit. Pääsolmu tekee tavanomaisen työn määrittääkseen skeeman XML-tiedostolle, mutta on olemassa muutamia muita komponentteja, joista olemme erityisesti huolissamme:
- varmuuskopioGlobals. Tämä liittyy itse asiassa huomautukseen, jonka voimme tehdä lähdekoodissamme. Globaalit ovat jotain, jota meidän pitäisi yrittää välttää olio-ohjelmoinnissa, mutta jos päätät käyttää sellaista tai joudut käyttämään sellaista, tämä käskee PHPUnitin käsittelemään globaalien muuttujien ylläpitämiä arvoja (ja antaa sinulle mahdollisuuden palauttaa niitä). Yleensä jätän tämän ennalleen.
- bootstrap. Tämä on valinnainen, mutta jos päätät sisällyttää testiisi muita tiedostoja (kuten tuoda pilaava kirjasto, osa WordPressistä tai kolmannen osapuolen kirjasto), tämä auttaa sinua määrittämään skriptin sijainnin, joka tarvitsee suorittaa. WordPressin pilkkaaminen ja tuominen ei kuulu tämän postauksen piiriin, mutta tulemme todennäköisesti tarkastelemaan sitä tulevaisuudessa, koska siitä on hyötyä laajennuksia testattaessa. Toistaiseksi aion sisällyttää yksinkertaisen automaattilatausohjelman, joka periaatteessa lisää kaikki tiedostot projektihakemiston juureen. Sen täydellinen lähde jaetaan myöhemmin tässä viestissä.
- värit. Jos haluat, että konsoli tulostaa raportin testeistäsi ja käyttää värejä (jotta helpottaa varoitusten, huomautusten, virheiden ja niin edelleen tunnistamista), aseta tämä arvoksi tosi.
- Seuraavat ovat kaikki loogisia arvoja. Suosittelen, että asetat ne todeksi, jotta saat mahdollisimman aggressiivisia raportteja. Tällä tavalla et pääse eroon siitä, että ilmoitukset tai varoitukset lipsahtavat läpi samalla kun olet huolissasi virheistä. Tämä on enemmän koodin laadun harjoittelua kuin mikään muu.
  - convertErrorsToExceptions
  - convertNoticesToExceptions
  - muuntaa WarningsToExceptions
testisarjat koostuvat testikokoelmista. Koska tietyssä projektissa voi olla useita testejä, on tärkeää varmistaa, että annat jokaiselle sarjalle yksilöllisen nimen ja viittaat oikean polun testiryhmään. Esimerkissämme meillä on vain yksi testipaketti ja se sijaitsee testihakemistossa.
loki on ominaisuus, joka voi olla niinkin yksinkertaista kuin tietojen tulostaminen konsoliin tai kolmannen osapuolen kirjaston (kuten Clover) käyttäminen raporttien luomiseen, jotka auttavat jatkuvassa integraatiossa. Koska en ole vielä keskustellut jälkimmäisestä missään aiemmissa viesteissäni, aiomme pysyä konsolissa pääasiallisena tulostusmenetelmänämme. Siten php ://stdout on ainoa lokitulostamme.

Kaiken tämän jälkeen XML-tiedostossamme on kaikki mitä PHPUnit tarvitsee toimiakseen ilman muita parametreja.

Muista kuitenkin, ennen kuin jatkat tämän artikkelin loppuun, oletan, että olet asentanut PHPUnitin maailmanlaajuisesti järjestelmääsi Composerin avulla. Jos ei, tutustu tähän artikkeliin, sillä se sisältää ohjeet sen tekemiseen.

Kun olet valmis, voit varmistaa, että PHPUnit on asennettu kirjoittamalla seuraavan komennon päätteeseen:

$ which phpunit

Ja sinun pitäisi nähdä jotain seuraavanlaista:

Jos näet jotain yllä olevan kaltaista, voit suorittaa PHPUnitin missä tahansa järjestelmässäsi.

3 Bootstrap-tiedosto

Ennen kuin jatkat, kirjoitetaan perus bootstrap-tiedosto. Kutsumme sitä nimellä bootstrap.php ja pudotamme sen testihakemistoomme. Se sisältää seuraavat:

<?php
// This array has a single file but could whole the contents of an entire directory.
$files = [
    dirname(__DIR__).'/AcmeCache.php',
];

foreach ($files as $file) {
    if (file_exists($file)) {
        require_once $file;
    }
}

Tämä on yksinkertainen "autoloader" (jota epäröimättä kutsun sillä, koska se vain toistaa tiedostoja ja vaatii niitä, mutta se toimii meidän tarkoituksissamme).

Tässä vaiheessa tehdään perustesti.

4 Perustesti, hylätty

Jos luet jotain testilähtöisestä kehityksestä, kuulet todennäköisesti punavihreän toiston syklistä. Siitä on paljon sanottavaa, ja suosittelen sen lukemista, mutta se ei ole tämän viestin tarkoitus.

Sen sijaan keskitymme enemmän siihen, että kirjoitamme testejä, jotka vastaavat sitä, mitä meidän on tehtävä, eikö niin? Tehdään sitten näin:

luo hakemisto, josta sinulla on joitain PHP-perustiedostoja, joita testaamme,
luo hakemiston juureen myös phpunit.xml ja täytä se käyttämällä aiemmin tässä viestissä jaettua koodia
Luo testihakemisto, johon sijoitamme testimme.

Vaihda nyt terminaalista hakemisto projektin hakemistoon (josta toistaiseksi puuttuu) ja suorita sitten php unit:

$ phpunit

Olettaen, että kaikki on asetettu oikein, sinun pitäisi nähdä jotain tällaista:

Koska meillä ei ole koodia eikä testejä, näemme luonnollisesti yllä olevan tulosteen, eikö niin? Joten kirjoitetaan yksi testi, joka suoritetaan (ja epäonnistuu), koska sille ei ole varsinaista testattavaa koodia.

Luo ensin testihakemistoon tiedosto nimeltä AcmeCacheTest.php. Ja annetaan sen tehdä jotain yksinkertaista, kuten luoda välimuistiobjekti, jonka lopulta luomme.

<?php

namespace AcmeTests;

use PHPUnitFrameworkTestCase;
use AcmeAcmeCache;

class AcmeCacheTest extends TestCase
{
    private $cache;

    public function setUp()
    {
        $this->cache = new AcmeCache();
    }

    public function testCacheExists()
    {
        $this->assertNotNull($this->cache);
    }
}

Ennen testin suorittamista huomaa, että:

Varmista, että käytät PHPUnitFrameworkTestCasea
Ja anna luokkamme laajentaa TestCasea

Tämä on osa sitä, mikä tekee PHPUnitin käytöstä niin helppoa. Kun tämä on tehty, suorita seuraava koodi projektisi juuresta:

$ phpunit

Sen jälkeen sinun pitäisi nähdä seuraava:

Huomaa, että tämä antaa epäonnistuneen testin ja kertoo, mistä ongelma löydettiin, tiedostosta ja rivistä.

Tämän korjaamiseksi meidän on kirjoitettava luokka:

<?php

namespace Acme;

class AcmeCache
{
    private $duration;

    public function __construct()
    {
        $this->duration = 43200;
    }

    public function setDuration(int $duration)
    {
        $this->duration = $duration;
    }

    public function getDuration(): int
    {
        return $this->duration;
    }
}

4 Muutama perustesti, läpäisevä testi

Perusläpäisykoe (joka perustuu edelliseen koodiin) sisältää seuraavat:

nimivälillä oleva tiedosto,
edustaa yksinkertaista välimuistia,
PHPUnit lataa sen automaattisesti käyttämällä yllä jaettua bootstrap.php – tiedostoa
ja sen rakentajassa on asetettu kesto sekä arvon asettaja ja getteri

Testataan ensin, että pystymme määrittämään luokan ja ettei se ole tyhjä. Tämä on hieman tarpeeton väite, koska tiedämme, että meillä on luokka oikein instantoituna, mutta se vie meidät kokeiden kirjoittamisen uraan:

<?php

namespace AcmeTests;

use PHPUnitFrameworkTestCase;
use AcmeAcmeCache;

class AcmeCacheTest extends TestCase
{
    private $cache;

    public function setUp()
    {
        $this->cache = new AcmeCache();
    }

    public function testCacheExists()
    {
        $this->assertNotNull($this->cache);
    }
}

Ja suorita testi:

Seuraavaksi tarkistetaan, että välimuistin oletusarvo on asetettu:

<?php

namespace AcmeTests;

use PHPUnitFrameworkTestCase;
use AcmeAcmeCache;

class AcmeCacheTest extends TestCase
{
    private $cache;

    public function setUp()
    {
        $this->cache = new AcmeCache();
    }

    public function testCacheExists()
    {
        $this->assertNotNull($this->cache);
    }

    public function testDefaultCacheValue()
    {
        $this->assertSame(43200, $this->cache->getDuration());
    }
}

Suorita testit edellisen vaiheen tapaan, ja sinun pitäisi nyt nähdä kaksi läpäisevää testiä:

Lopuksi testataan, voimmeko muuttaa arvoa onnistuneesti:

<?php

namespace AcmeTests;

use PHPUnitFrameworkTestCase;
use AcmeAcmeCache;

class AcmeCacheTest extends TestCase
{
    private $cache;

    public function setUp()
    {
        $this->cache = new AcmeCache();
    }

    public function testCacheExists()
    {
        $this->assertNotNull($this->cache);
    }

    public function testDefaultCacheValue()
    {
        $this->assertSame(43200, $this->cache->getDuration());
    }

    public function testSetCustomDuration()
    {
        $duration = 4200;

        $this->cache->setDuration($duration);
        $this->assertSame($duration, $this->cache->getDuration());
    }
}

Ja kolme viimeistä läpäisykoetta:

Ja siinä se on:

PHPUnit XML -tiedosto,
yksinkertainen bootstrap,
yksi, nimivälitetty luokka,
yksikkötestit jokaiselle luokan menetelmälle

Myönnettäköön, se on yksinkertaista, mutta tämä antaa perusteet paljon enemmän kuin mitä monet ihmiset jo tekevät testeillään.

Lisäksi se antaa sinulle rakentamisen varaa, kun testikyljyksesi vahvistuvat.

Onko enemmän? (Aina oikeassa?)

Lopuksi, jos olet innokas todella sukeltamaan asetustiedostoon, voit lukea sen käsikirjan perusteellisen selityksen.

Huomaa kuitenkin, että kaikki yllä kuvattu pyrkii olemaan sitä, mitä tarvitset oman PHPUnit XML -asetustiedoston määrittämisen aloittamiseen.

: tommcfarlin.com