Menulis ujian berkualiti tinggi

Malangnya, ujian masih tidak mendapat perhatian yang sepatutnya mereka perolehi dalam banyak organisasi. Kadangkala ia berasa seperti pembangun berasa bersalah jika mereka tidak menulis sebarang ujian, dan pada masa yang sama kod ujian sering tidak disemak dengan betul. Sebaliknya, satu-satunya perkara yang sering disemak dalam semakan adalah jika terdapat sebarang ujian, yang memalukan, kerana sekadar mempunyai ujian tidak cukup baik. Sebenarnya, mereka harus sekurang-kurangnya mempunyai kualiti yang sama seperti semua kod lain dalam projek, jika bukan kualiti yang lebih tinggi. Jika tidak, ujian mungkin menghalang anda, kerana ujian gagal terlalu kerap, sukar difahami atau mengambil masa terlalu lama untuk dijalankan. Saya telah membincangkan beberapa perkara ini dalam catatan blog saya tentang menggunakan pelaksanaan dalam memori dan bukannya olok-olok repositori. Sekarang saya ingin membincangkan beberapa perkara lain yang lebih umum, yang saya perhatikan semasa menulis ujian.

Minimalisme adalah kunci

Limpahan Tindanan meminta anda menambah contoh minimum yang boleh diterbitkan semula pada soalan, dan pada pendapat saya ini juga merupakan nasihat yang sangat baik untuk menulis ujian atas sebab yang sama. Terutama apabila membaca ujian beberapa bulan selepas anda menulisnya, adalah lebih mudah untuk memahami sepenuhnya apa yang berlaku jika kurang perkara yang berlaku. Jadi hanya tulis kod yang benar-benar diperlukan untuk ujian dan tahan godaan untuk menambah lebih banyak bahan hanya kerana mudah untuk melakukannya. Tetapi kod ujian sudah tentu mesti masih lengkap, iaitu ujian harus mengandungi seberapa banyak baris yang diperlukan, tetapi sesedikit mungkin.

Pergi untuk liputan kod 100%.

Itu mungkin pendapat yang tidak popular, tetapi saya fikir adalah masuk akal untuk menyasarkan liputan kod 100%, walaupun ramai nampaknya menganggap ini sebagai amalan buruk.

Kadangkala pasukan berpuas hati dengan nilai yang lebih rendah, mis. liputan kod sebanyak 90%. Namun, itu tidak masuk akal bagi saya. Pertama sekali, semua nombor ini agak sewenang-wenang dan sukar untuk disandarkan menggunakan data. Selain itu, apabila menulis kod baharu, tidak semuanya perlu diuji untuk melepasi ambang tersebut. Dan jika seseorang berjaya mendapatkan liputan, orang seterusnya boleh melepaskan diri dengan tidak menulis sebarang ujian sama sekali sambil mengekalkan liputan kod lebih tinggi daripada 90%, yang mengakibatkan perasaan yakin yang salah.

Salah satu alasan yang sering saya dengar ialah tidak masuk akal untuk menulis ujian untuk fungsi mudah seperti getter dan setter. Dan mungkin mengejutkan, saya sangat bersetuju dengan itu. Tetapi inilah tangkapannya: Jika tiada ujian yang benar-benar menggunakan getter dan setter ini, maka mungkin tidak perlu memilikinya. Jadi, daripada merungut tentang betapa sukarnya untuk mencapai liputan ujian 100%, kemungkinan besar adalah lebih baik untuk tidak menulis kod yang tidak diperlukan pada mulanya. Ini juga mengelakkan beban penyelenggaraan yang dibawa oleh setiap baris kod.

Walau bagaimanapun, terdapat sedikit tangkapan: Kadangkala kod melakukan perkara pelik, yang mungkin menyebabkan alat liputan kod menandai beberapa baris sebagai tidak bertutup, walaupun ia telah dilaksanakan semasa ujian dijalankan. Saya tidak banyak menghadapi situasi seperti ini, tetapi jika tidak ada cara untuk membuat ini berfungsi, saya mengecualikan mereka daripada liputan kod. Cth. PHPUnit membenarkan untuk melakukannya menggunakan anotasi codeCoverageAbaikan mereka:

<?php

class SomeClass
{
    /**
     * @codeCoverageIgnore
     */
    public function doSomethingNotDetectedAsCovered()
    {

    }
}

Dengan cara ini fungsi ini tidak termasuk dalam analisis liputan kod, yang bermaksud masih mungkin untuk mencapai liputan kod sebanyak 100%, dan saya juga terus menyemak nilai itu. Alternatifnya adalah untuk menyelesaikan nilai yang lebih rendah daripada 100%, tetapi kemudian terdapat isu yang sama yang dinyatakan di atas: Kod lain mungkin juga tidak dilindungi oleh ujian dan itu mungkin terlepas.

Dengan itu, liputan kod 100% pastinya tidak memberikan sebarang jaminan bahawa kod anda tidak mempunyai sebarang pepijat. Tetapi jika anda telah menemui baris dalam kod aplikasi anda, anda tidak memberikan ujian anda perubahan untuk mengesan kemungkinan ralat dalam baris itu.

Tulis pernyataan yang baik

Sebab ujian sedang ditulis ialah kami ingin menegaskan tingkah laku tertentu kod tersebut. Oleh itu penegasan adalah bahagian yang sangat penting dalam ujian.

Sudah tentu pertimbangan yang paling penting semasa menulis penegasan ialah ia menguji tingkah laku kod dengan betul. Tetapi detik yang sangat dekat ialah bagaimana pernyataan itu bertindak apabila kod itu gagal. Jika dakwaan gagal atas apa jua sebab, masalahnya haruslah jelas kepada pembangun yang mungkin. Situasi di mana ini jelas ialah situasi yang sedang diusahakan dalam permintaan tarik Symfony ini. Symfony datang dengan kaedah assertResponseStatusCodeSame, yang membolehkan untuk menyemak kod status respons dalam ujian berfungsi:

<?php

declare(strict_types=1);

class LoginControllerTest extends WebTestCase
{
    public function testFormAttributes(): void
    {
        $client = static::createClient();

        $client->request('GET', '/login');
        $this->assertResponseStatusCodeSame(200);

        $this->assertSelectorCount(1, 'input[name="email"][required]');
    }
}

Masalah dengan ujian ini ialah output yang dijana sekiranya kod status bukan 200. Memandangkan ujian biasanya dijalankan dalam persekitaran pembangunan, Symfony akan mengembalikan halaman ralat apabila URL ini diakses dan kaedah assertResponseStatusCodeSame akan mengeluarkan keseluruhan respons sekiranya pernyataan itu gagal. Output ini sangat panjang, kerana ini bukan sahaja mengembalikan HTML, tetapi juga CSS dan JavaScript, dan penimbal skrol balik saya sebenarnya terlalu kecil untuk membolehkan saya membaca keseluruhan mesej.

Ini benar-benar contoh paling teruk yang saya temui setakat ini, tetapi ia juga boleh menjengkelkan jika pernyataan yang salah digunakan dalam kod. Mari kita lihat pada output penegasan assertSelectorCount di atas, yang gagal dengan mesej berikut jika pemilih yang diberikan tidak menghasilkan tepat satu elemen:

Failed asserting that the Crawler selector "input[name="email"][required]" was expected to be found 1 time(s) but was found 0 time(s).

Ia memberikan idea yang cukup bagus tentang masalah yang berlaku. Walau bagaimanapun, penegasan itu juga boleh ditulis dengan cara yang berbeza (jangan lakukan ini di rumah!):

<?php

class SomeClass
{
    /**
     * @codeCoverageIgnore
     */
    public function doSomethingNotDetectedAsCovered()
    {

    }
}

Seseorang mungkin berpendapat bahawa ini melakukan perkara yang sama, oleh itu tidak kira varian mana yang digunakan. Ini tidak boleh jauh dari kebenaran, kerana mesej berikut muncul jika tidak ada satu medan input yang diperlukan untuk e-mel:

<?php

declare(strict_types=1);

class LoginControllerTest extends WebTestCase
{
    public function testFormAttributes(): void
    {
        $client = static::createClient();

        $client->request('GET', '/login');
        $this->assertResponseStatusCodeSame(200);

        $this->assertSelectorCount(1, 'input[name="email"][required]');
    }
}

Ini tidak membantu sama sekali, dan sesiapa yang berusaha menyelesaikan masalah itu terlebih dahulu perlu mengetahui masalah sebenarnya. Apa yang ditunjukkan ini, ialah penegasan yang sentiasa sesuai harus digunakan, dan PHPUnit datang dengan banyak pernyataan yang sesuai dengan semua jenis kes penggunaan. Kadangkala ia juga masuk akal untuk membuat penegasan tersuai.

Pernyataan yang agak baharu yang saya lihat semakin popular dalam beberapa tahun kebelakangan ini ialah ujian syot kilat. Terutama apabila mula bekerja pada projek bahagian hadapan nampaknya banyak membantu. Saya sering menggunakannya dengan React pada masa lalu. Intipati utama ialah ujian anda kelihatan seperti ini:

Failed asserting that the Crawler selector "input[name="email"][required]" was expected to be found 1 time(s) but was found 0 time(s).

Keajaiban berlaku dalam kaedah toMatchSnapshot. Dalam larian pertama ia menulis kandungan pembolehubah pokok ke dalam fail berasingan. Pada larian berikutnya ia membandingkan nilai baharu nilai pokok dengan apa yang telah disimpan sebelum ini dalam fail berasingannya. Jika sesuatu berubah, ia akan gagal dalam ujian dan menunjukkan perbezaan, dengan pilihan untuk mengemas kini gambar semula, yang bermaksud anda boleh membetulkan ujian anda dalam sekelip mata.

Walaupun ini kedengaran sangat bagus, ia juga mempunyai beberapa kelemahan. Pertama, syot kilat agak rapuh, kerana setiap kali penanda yang diberikan bagi Komponen berubah, ujian akan gagal. Kedua, niat ujian disembunyikan, kerana ia tidak menjelaskan perkara yang sebenarnya ingin diuji oleh pengarang.

Walau bagaimanapun, perkara yang sangat saya sukai mengenainya ialah apabila saya menukar komponen, ia mengingatkan saya tentang semua komponen lain yang menggunakan komponen itu, kerana semua syot kilat tersebut gagal pada larian seterusnya. Atas sebab ini saya suka mempunyai sekurang-kurangnya satu ujian syot kilat bagi setiap komponen.

Kesimpulan

Jadi, secara ringkasnya, saya rasa terdapat beberapa perkara yang boleh anda mula lakukan dengan segera untuk meningkatkan kualiti ujian anda:

• Simpan kod dalam ujian pada tahap minimum yang diperlukan
• Sasarkan liputan kod 100% dan kecualikan kod dengan betul daripada mekanisme liputan kod jika ia tidak dapat diuji
• Gunakan pernyataan yang betul untuk mendapatkan mesej ralat yang lebih baik apabila ujian anda gagal

Pada pendapat saya, mengikuti beberapa peraturan ini sudah akan membuat perubahan besar dan membantu anda menikmati bekerja dalam pangkalan kod untuk masa yang lama!

Atas ialah kandungan terperinci Menulis ujian berkualiti tinggi. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!