Kirjutamisüksuste testid PHPUnitiga, 3. osa: XML-i konfiguratsioon

Viimati uuendatud nov. 29, 2022

Sisu

PHPUnit XML konfiguratsioon

1 Failide väljajätmine

2 Konfiguratsioonifaili põhitõed

3 Bootstrap fail

4 Ebaõnnestunud põhitest

4 Mõned põhilised testid

Kas on veel? (Alati õigus?)

Selle seeria varasemates postitustes olen käsitlenud kahte järgmist teemat:

Kirjutamisüksuse testid PHPUnitiga, 1. osa: Seadistamine. Juhend PHPUniti testide kirjutamise alustamiseks, kasutades põhivahemälu ja kasutades raamistiku häälestusmeetodit.
Kirjutamisosa testid PHPUnitiga, 2. osa: Rebimine. Õpetus selle kohta, kuidas kirjutada ühikuteste, mis kasutavad õigesti PHPUniti häälestus- ja rebimismeetodeid.

Kõik ülaltoodud on mõeldud andma aabitsa väga lihtsate ühikutestide kirjutamise alustamiseks. Asjad võivad muutuda keerulisemaks, eriti kui rakendus või projekt kasvab (aga see on alati tõsi, eks?).

Kuid selleks, et olla valmis selleks, on üksuse testimisel üks viimane komponent, millele peaksime minu arvates keskenduma, ja see on PHPUnit XML-i konfiguratsioonifaili mõistmine (mida olete võib-olla näinud teistes projektides kui phpunit.xml).

PHPUnit XML konfiguratsioon

Nii et selles postituses seadistan lihtsa projekti, mis kasutab PHPUniti, kirjutab mõned testid, nagu need, mida oleme juba näinud, ja kasutab testimise automatiseerimiseks konfiguratsioonifaili.

Lisaks teen kõik endast oleneva, et kõige paremini selgitada konfiguratsioonifaili vajalikke osi, et saaksite need lisada oma järgmisse projekti.

1 Failide väljajätmine

Enne testitava koodi kirjutamise alustamist on oluline teada failid, mida protsessi toimimiseks vaja läheb.

Järgnevalt kirjeldame enam-vähem, kuidas me korraldame asju projekti algusest peale:

testide kataloog,
faili phpunit.xml _

Lõpuks näete ka järgmist:

failid, millest projekt koosneb,
testid, mis kontrollivad nimetatud faile.

Siinkohal vaatame aga XML-i konfiguratsioonifaili ja proovime seejärel PHPUniti automaatselt ilma muude parameetriteta käivitada.

2 Konfiguratsioonifaili põhitõed

Kõigepealt vaatame põhikonfiguratsioonifaili:

<?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>

Nüüd mõistame, mida me täpselt vaatame (peale lihtsa XML-i).

phpunit. Vanemsõlm teeb XML-faili skeemi määratlemisel tavapärast tööd, kuid on veel mõned komponendid, mis puudutavad meid:
- backupGlobals. See on tegelikult seotud märkusega, mille saame oma lähtekoodi teha. Globaalseid väärtusi peaksime püüdma objektorienteeritud programmeerimisel vältida, kuid kui otsustate kasutada ühte või peate seda kasutama, käsib see PHPUnitil käsitleda väärtusi, mida globaalsed muutujad säilitavad (ja annab teile võimaluse taastada neid). Üldiselt jätan selle nii nagu on.
- bootstrap. See on valikuline, kuid kui otsustate oma testidesse kaasata ka muid faile (nt pilkava teegi, WordPressi osa või kolmanda osapoole teegi toomine), siis on see kõik, mida saate määrata skripti asukoha, mis vajab hukata. WordPressi mõnitamine ja toomine ei kuulu selle postituse ulatusse, kuid tõenäoliselt vaatame seda tulevikus, kuna see on pistikprogrammide testimisel kasulik. Praegu lisan lihtsa automaatlaaduri, mis põhimõtteliselt lisab kõik failid projekti kataloogi juurtesse. Selle täielikku allikat jagatakse hiljem selles postituses.
- värvid. Kui soovite, et konsool prindiks teie testide aruande välja ja kasutaks seda värvide abil (hoiatuste, märkuste, vigade jms hõlpsamaks tuvastamiseks), määrake see väärtuseks Tõene.
- Kõik järgmised on tõeväärtused. Soovitan määrata need tõeseks, et saada võimalikult agressiivseid aruandeid. Nii ei pääse te lihtsalt märguannetest või hoiatustest läbi, muretsedes ainult vigade pärast. See on pigem koodikvaliteedi harjutus kui miski muu.
  - convertErrorsToExceptions
  - convertNoticesToExceptions
  - teisendada hoiatused eranditeks
testikomplektid koosnevad testide kogumitest. Kuna antud projektil võib olla mitu testi, on oluline veenduda, et annate igale komplektile kordumatu nime ja viidate testide rühma õigele teele. Meie näites on meil ainult üks testkomplekt ja see asub testide kataloogis.
logimine on funktsioon, mis võib olla nii lihtne kui andmete väljatrükkimine konsooli või kolmanda osapoole teegi (nt Clover) kasutamine aruannete genereerimiseks, mis aitavad pidevat integreerimist. Kuna ma pole viimast üheski oma varasemas postituses veel arutanud, jääme oma peamise väljundmeetodina konsooli juurde. Seega on meie ainus logiväljund php ://stdout .

Kõike seda arvesse võttes on meie XML-failil kõik, mida PHPUnit vajab ilma muude parameetriteta.

Pidage siiski meeles, et ma eeldan, et olete enne selle artikli ülejäänud osaga jätkamist oma süsteemi PHPUniti globaalselt installinud, kasutades Composerit. Kui ei, siis vaadake see artikkel üle, sest see annab teile juhiseid selle kohta.

Kui see on tehtud, saate kontrollida, kas PHPUnit on installitud, sisestades terminali järgmise käsu:

$ which phpunit

Ja te peaksite nägema midagi sellist:

Kui näete midagi ülaltoodut, saate PHPUniti käivitada kõikjal oma süsteemist.

3 Bootstrap fail

Enne kui läheme edasi, kirjutame alglaadimisfaili. Nimetame selle nimeks bootstrap.php ja viskame selle oma testide kataloogi. See sisaldab järgmist:

<?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;
    }
}

See on lihtne "automaatne laadija" (mida ma kõhklevalt nii nimetan, kuna see lihtsalt kordab faile ja nõuab neid, kuid see töötab meie eesmärkidel).

Siinkohal paneme paika põhitesti.

4 Ebaõnnestunud põhitest

Kui loete midagi testipõhise arenduse kohta, kuulete tõenäoliselt punase-rohelise korduva tsükli kohta. Selle kohta on palju öelda ja ma soovitan selle kohta lugeda, kuid see pole selle postituse eesmärk.

Selle asemel oleme rohkem keskendunud testide kirjutamisele, mis vastavad sellele, mida me peame tegema, eks? Kui see öeldud, teeme järgmist.

looge kataloog, millest leiate mõned põhilised PHP-failid, mida me testime,
kataloogi juurtes looge ka phpunit.xml ja sisestage see selles postituses varem jagatud koodi abil
looge testide kataloog, kuhu paigutame oma testid.

Nüüd muutke terminalist kataloog projekti kataloogiks (mis praegu küll puudub) ja seejärel käivitage lihtsalt php unit:

$ phpunit

Eeldades, et kõik on õigesti seadistatud, peaksite nägema midagi sellist:

Kuna meil pole koodi ega teste, näeme loomulikult ülaltoodud väljundit, eks? Nii et kirjutame ühe testi, mis käivitatakse (ja ebaõnnestub), kuna selle testimiseks pole tegelikult koodi.

Esiteks looge testide kataloogis fail nimega AcmeCacheTest.php. Ja laske sellel teha midagi lihtsat, näiteks luua vahemäluobjekt, mille me lõpuks loome.

<?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);
    }
}

Enne testi käivitamist pange tähele, et:

Kasutage kindlasti PHPUnitFrameworkTestCase’i
Ja laske meie klassil TestCase’i laiendada

See on osa sellest, mis teeb PHPUniti kasutamise nii lihtsaks. Kui see on tehtud, käivitage oma projekti juurtest järgmine kood:

$ phpunit

Pärast seda peaksite nägema järgmist.

Pange tähele, et see annab ebaõnnestunud testi ja ütleb teile, kust probleem leiti, faili ja rea.

Selle parandamiseks peame kirjutama klassi:

<?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 Mõned põhilised testid

Põhiline läbimise test (mis põhineb eelmisel koodil) sisaldab järgmist:

nimeruumiga fail,
esindab lihtsat vahemälu,
PHPUnit laadib selle automaatselt, kasutades ülal jagatud faili bootstrap.php
ja selle konstruktoris on määratud kestus koos väärtuse määraja ja getteriga

Kõigepealt testime, kas suudame klassi seadistada ja et see pole null. See on pisut tarbetu väide, kuna me teame, et meil on klass õigesti instantseeritud, kuid see viib meid testide kirjutamise keerisesse:

<?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 käivitage test:

Järgmisena kontrollime, kas vahemälu vaikeväärtus on määratud:

<?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());
    }
}

Nagu eelmises etapis, käivitage testid ja nüüd peaksite nägema kahte läbivat testi:

Lõpuks testime, kas suudame väärtust edukalt muuta:

<?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 kolm viimast läbitud testi:

Ja seal see on:

PHPUnit XML-fail,
lihtne bootstrap,
üks, nimeruumiga klass,
ühikutestid klassi iga meetodi jaoks

Tõsi, see on lihtne, kuid see loob põhialused palju enamaks kui see, mida paljud inimesed oma testidega juba teevad.

Lisaks annab see teile midagi, millele tugineda, kui teie testitavad kotletid muutuvad tugevamaks.

Kas on veel? (Alati õigus?)

Lõpuks, kui soovite tõesti konfiguratsioonifaili sukelduda, võite lugeda juhendi põhjalikku selgitust selle kohta.

Pange tähele, et kõik ülalkirjeldatu eesmärk on olla see, mida vajate oma PHPUnit XML-i konfiguratsioonifaili seadistamise alustamiseks.

: tommcfarlin.com