Memfokuskan ujian anda pada domain. Contoh PHPUnit

pengenalan

Banyak kali pembangun cuba menguji 100% (atau hampir 100%) kod mereka. Nampaknya, ini adalah matlamat yang harus dicapai oleh setiap pasukan untuk projek mereka tetapi, dari sudut pandangan saya, hanya satu bahagian daripada keseluruhan kod yang harus diuji sepenuhnya: Domain anda.

Domain adalah, pada asasnya, bahagian kod anda yang mentakrifkan perkara yang sebenarnya dilakukan oleh projek itu. Sebagai contoh, apabila anda mengekalkan entiti kepada pangkalan data, domain anda tidak bertanggungjawab untuk meneruskannya pada pangkalan data, tetapi memastikan bahawa data yang berterusan masuk akal mengikut model perniagaan anda. Mungkin, apabila anda menyimpan data anda pada pangkalan data, anda akan menggunakan perpustakaan luaran seperti PHP Doctrine. Perpustakaan ini sudah diuji sepenuhnya, tidak perlu menguji apa yang dilakukannya. Jika anda meneruskan kepada doktrin data yang betul, ia akan disimpan ke pangkalan data tanpa sebarang masalah.

Contoh yang ditunjukkan dalam bahagian berikut tidak cuba menunjukkan cara Reka Bentuk Didorong Domain berfungsi, terdapat banyak artikel yang menerangkannya dengan baik. Saya akan cuba menunjukkan bagaimana domain anda ditakrifkan dan dipisahkan dengan baik boleh membantu untuk menguji dengan mudah dan memfokuskan pada perkara yang dilakukan oleh aplikasi anda.

Contohnya dibina di atas persekitaran Symfony dan menggunakan pustaka PHPUnit, tetapi idea itu sah untuk mana-mana bahasa atau rangka kerja.

Kod untuk diuji

Mari bayangkan aplikasi kami bersambung ke api luaran yang mengembalikan data tentang kebarangkalian hujan untuk tarikh tertentu. Data yang dikembalikan kelihatan seperti ini:

{
   "date" : "2022-12-01",
   "rain_probability" : 0.75
}

Sekarang, kita perlu mengambil data tersebut dan mengklasifikasikannya mengikut pemetaan ini:

• kebarangkalian_hujan RENDAH
• kebarangkalian_hujan ≥ 0.40 && kebarangkalian_hujan SEDERHANA
• kebarangkalian_hujan ≥ 0.75: TINGGI

dan simpan hasilnya pada jadual pangkalan data yang diterangkan oleh entiti berikut:

#[ORM\Entity(repositoryClass: RainMeasure::class)]
class RainMeasure {

    #[ORM\Column]
    private string $date;

    #[ORM\Column]
    private float $probability;

    #[ORM\Column(length: 10)]
    private string $label;

    // Getters and setters
    // .......
}

Mari kita buat pengendali yang mendapat data api luaran, menetapkan label mengikut kebarangkalian hujan dan menyimpannya ke pangkalan data.

class RainMeassureHandler {
    private EntityManagerInterface $em;

    public function __construct(EntityManagerInterface $em)
    {
        $this->em = $em;
    }

    public function saveMeasure(array $measureData): void
    {
        if($measureData['rain_probability'] = 0.40 && $measureData['rain_probability'] setDate($measureData['date']);
        $rainMeasure->setProbability($measureData['rain_probability']);
        $rainMeasure->setLabel($label);

        $this->em->persist($rainMeasure);
        $this->em->flush();
    }
}

Jika kami cuba membuat ujian untuk pengendali di atas, kami akan mendapati bahawa kami perlu menyuntik EntityManagerInterface kerana tingkah laku yang ingin kami uji (menetapkan label mengikut nilai kebarangkalian) adalah digabungkan dalam pengendali yang sama yang menyimpan hasilnya ke pangkalan data. Kita boleh cuba memuatkan EntityManagerInterface menggunakan olok-olok dan stub tetapi, adakah ia perlu ?. Jelas sekali tidak. Seperti yang dinyatakan sebelum ini, kita harus cuba menumpukan pada menguji tingkah laku yang dimiliki oleh domain kita, yang mendapat label yang betul mengikut kebarangkalian hujan.

Tingkah laku decoupling yang ingin kami uji

Untuk memudahkan ujian kami, kami akan mengalihkan tingkah laku yang ingin kami uji ke kelas lain:

class RainMeasureLabelHandler 
{
    public function getLabelFromProbability(float $prob): string
    {
        if($prob = 0.40 && $prob 

<p>Dan kini, RainMeassureHandler kami akan kelihatan seperti ini:</p>

<pre class="brush:php;toolbar:false">

class RainMeasureHandler 
{
    private EntityManagerInterface $em;

    public function __construct(EntityManagerInterface $em)
    {
        $this->em = $em;
    }

    public function saveMeasure(array $measureData): void
    {
        $rainMeasureLabelHandler = new RainMeasureLabelHandler();
        $label = $rainMeasureLabelHandler->getLabelFromProbability($measureData['rain_probability']);

        $rainMeasure = new RainMeasure();
        $rainMeasure->setDate($measureData['date']);
        $rainMeasure->setProbability($measureData['rain_probability']);
        $rainMeasure->setLabel($label);

        $this->em->persist($rainMeasure);
        $this->em->flush();
    }
}

Kini kami boleh menumpukan pada ujian RainMeasureLabelHandler kami yang akan menjadi sebahagian daripada domain kami dan tidak akan mempunyai kebergantungan pada lapisan luaran. Mengujinya semudah yang ditunjukkan:

Kesimpulan

Saya ingin mengatakan bahawa jenis ujian lain juga berguna. Mungkin kami mempunyai api dan kami ingin menguji input dan output dengan persekitaran ujian yang merangkumi pangkalan data dan sumber lain yang kami perlukan. Tetapi, ingat bahawa domain anda dipisahkan dan diuji sepenuhnya.

Atas ialah kandungan terperinci Memfokuskan ujian anda pada domain. Contoh PHPUnit. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!