Tip dan trik PHPUnit

Posted on

[ad_1]

Dalam artikel saya sebelumnya, Pengujian Unit PHP dengan PHPUnit dan Menggunakan Mocks and Stubs di PHPUnit, saya telah menunjukkan cara menyiapkan PHPUnit dan cara memulai pengujian unit dan cara mengelola objek stubbing dan mocking untuk mengisolasi kode Anda secara efektif di bawah ini. tes. Artikel ini mengeksplorasi beberapa cara untuk mendapatkan hasil maksimal dari pengujian PHPUnit Anda.

Pengarang: Kendrick Curtis, Perangkat Lunak Stainless, http://www.stainless-software.com/

Bekerja dengan metode statis

Setiap basis kode PHP berorientasi objek yang cukup besar kemungkinan akan berisi beberapa metode statis, dan metode ini seringkali memerlukan pengujian yang lebih menyeluruh daripada banyak metode kelas, terutama jika metode tersebut adalah lajang atau pabrik yang kuat.

Menguji metode ini mudah: buat kelas pengujian secara normal dan panggil metode statis sebagai kode yang diuji, dan hapus kode apa pun yang memanggil metode statis. Namun, mencoba menguji metode lain yang mengandalkan metode statis ini bermasalah: Anda tidak dapat mengejek menggunakan metode statis. $this->getMock(“classname”) Seperti yang Anda duga. Jika Anda menggunakan PHP5.3+ dan PHPUnit3.5+, Anda dapat meniru statis dalam keadaan yang sangat terbatas. Penulis PHPUnit Sebastian Bergmann telah mendokumentasikan ini di blognya tetapi tidak di manual PHPUnit.

PHPUnit

Sebagai gantinya, Anda harus memodifikasi kode produksi Anda untuk mengonversi metode statis Anda menjadi metode non-statis, berpotensi membuat kelas baru untuk mengakomodasi fungsionalitas statis sebagaimana diperlukan. Jadi Anda akan berakhir dengan kode Anda seperti ini:

class CodeUnderTest
{
function useStatic()
{
$static = new Static();
$static->method();
}
}

Tapi tentu saja, “baru” tidak dapat bertahan dalam metode useStatic untuk mematikan, jadi Anda harus benar-benar melakukan ini:

class CodeUnderTest
{
function newStatic()
{
return new Static();
}
function useStatic()
{
$static = $this->newStatic();
$static->method();
}
}

Ini hampir tidak ringkas, tetapi setidaknya bekerja dengan cara yang persis sama saat membuat objek non-statis untuk pengujian.

Bekerja dengan Framework

Pola MVC standar yang digunakan oleh banyak framework, termasuk Zend, Cake, Yii, dan lainnya, semuanya bergantung pada kombinasi router dan satu set pengontrol. Menguji kinerja router semacam itu sulit dan harus benar-benar diserahkan kepada pembuat kerangka kerja yang Anda gunakan. Jika router Anda mengandalkan beberapa logika kompleks – misalnya, untuk mem-parsing URL dengan cara tertentu – cukup mudah untuk mengkode penguraian URL tersebut dalam metode terpisah di kelas router atau di kelas terpisah yang dipakai. Setelah bagian dari lapisan logika bisnis Anda dihapus dari router, pengujiannya cukup sederhana.

Anda mungkin tergoda untuk menulis kode untuk menguji fungsionalitas pengontrol itu sendiri, tetapi hal ini dapat menyebabkan segala macam sakit kepala: bergantung pada cara kerja aplikasi Anda, pengontrol dapat menulis langsung ke aliran keluaran. Anda dapat menyangga data ini, tetapi menurut saya yang terbaik adalah menguji elemen yang diandalkan oleh pengontrol Anda terlebih dahulu sebelum mengkhawatirkan apakah pengontrol Anda menggunakan logika bisnis Anda dengan benar. Jika pengontrol Anda memiliki persyaratan pengambilan keputusan kompleks yang signifikan, pertimbangkan apakah itu harus ditempatkan di pustaka yang lebih mudah diuji dan terpisah dari pengontrol.

Bekerja dengan database

Pengujian otomatis yang melibatkan database selalu memusingkan. Anda memiliki dua pilihan dasar:

  • Atau pertahankan basis data pengujian dan pastikan bahwa setiap rangkaian pengujian unit selalu mengembalikan basis data ke status yang sama (yang bisa berupa skema kosong, yang diisi konfigurasi Anda dengan data yang relevan) – Opsi ini sangat memakan waktu dan basis data Anda lebih besar . Menjadi lebih sulit untuk menjamin bahwa Anda dapat kembali ke keadaan stabil.
  • Atau, hapus kode akses DB Anda dan verifikasi bahwa kode Anda yang sedang diuji memanggil permintaan yang Anda harapkan. Sayangnya, jika antarmuka DB Anda berbasis SQL, Anda dapat mengalami semua jenis masalah saat mem-parsing string SQL yang tidak identik secara tekstual, tetapi identik secara fungsional (karena perbedaan spasi putih, perbedaan gaya kutipan, dll.).

Untungnya, sebagian besar kerangka kerja modern mengintegrasikan bahasa kueri DB non-SQL ke dalam PHP sebagai kelas dan metode yang dapat Anda hapus secara rutin. Untuk testabilitas, ini adalah hasil yang paling disukai. Namun, opsi ketiga adalah mengkodekan semua kueri DB Anda di RDBMS Anda sebagai prosedur dan kemudian hanya mereferensikan prosedur dalam kode PHP Anda. Dalam contoh ini, menguji pemanggilan prosedur DB secara signifikan lebih sederhana daripada menghentikan dan mengejek beberapa objek dan metode kueri PHP.

Pengujian unit yang efektif untuk proyek yang ada

Melihat proyek yang sudah ada dan mempertimbangkan untuk menambahkan pengujian unit dapat menjadi hal yang menakutkan hanya karena banyaknya kode yang terlibat. Terutama di organisasi komersial, di mana menambahkan pengujian unit bisa menjadi kurang penting daripada memperbaiki bug dan mengembangkan fitur. Sayangnya, hanya sedikit tempat kerja yang mengutamakan kualitas kode.

Dalam hal ini, pengujian unit saat dijalankan terhadap bagian yang benar-benar penting dari aplikasi kemungkinan besar akan berdampak paling besar, dan itu berarti memahami basis kode dan domain bisnis Anda. Misalnya, jika situs Anda adalah broker asuransi, maka kode yang memastikan bahwa harga yang Anda berikan kepada pelanggan selalu lebih tinggi daripada harga yang Anda bayarkan untuk tautan afiliasi ditambah biaya penjamin emisi mungkin merupakan potongan kode yang paling penting di situs tersebut. . Pertama, tulis pengujian untuk kode ini dan pastikan pengujian Anda mencakup 100% pohon keputusan dari modul penting ini. Yang paling penting, selalu perbarui pengujian saat kode berkembang.

Pengujian unit yang efektif untuk proyek baru

Saat Anda memulai proyek dari batu tulis kosong, itu adalah permainan bola yang sangat berbeda. Anda memiliki kesempatan untuk menggunakan pengembangan berbasis pengujian (TDD), di mana pengujian ditulis sebelum atau pada waktu yang sama dengan kode yang sedang diuji.

Namun, kualitas membutuhkan waktu dibandingkan dengan terburu-buru tanpa TDD. Organisasi Anda harus memahami dan menganut gagasan TDD, atau setidaknya pengujian unit untuk beberapa kode spesifikasi tinggi, sehingga Anda sebagai pengembang memiliki waktu khusus untuk menulis pengujian unit. Tidak semua manajer setuju bahwa Anda memerlukan cakupan garis dan keputusan 100% di seluruh program Anda, dan mereka mungkin benar! Banyak kode web saat ini adalah tentang menempel di perpustakaan yang dipahami dengan baik untuk menghasilkan jenis keluaran umum seperti tabel dan grafik di halaman web. Banyak dari kode ini tidak penting bagi bisnis dalam arti bahwa jika tidak berfungsi dengan baik, bisnis akan mulai kehilangan uang: pertimbangkan bagian mana dari aplikasi Anda yang benar-benar memerlukan pengujian unit untuk memastikan kebenarannya. Pastikan, dan tulis pengujian unit di daerah tersebut dari awal. .

Versi dan integrasi berkelanjutan

Tes unit tidak berguna jika tidak cocok dengan kode produksi yang terkait dengannya, jadi penting untuk memeriksanya ke dalam sistem versi kode yang sama dengan kode itu sendiri. SVN dan git saat ini merupakan alat kontrol versi paling populer.

Jika kode dan pengujian Anda berada dalam repositori kontrol versi yang sama, Anda dapat mempertimbangkan untuk membangun server integrasi berkelanjutan yang secara otomatis menjalankan pengujian terhadap kode baru apa pun yang diperiksa dan memberi tahu Anda jika pengujian mulai gagal. . Integrasi berkelanjutan untuk PHP biasanya disediakan menggunakan Hudson atau Jenkins.

Tentang Penulis

Kendrick Curtis adalah pengembang web dengan pengalaman sepuluh tahun. Dia adalah salah satu pendiri Stainless Software, sebuah perusahaan desain, pengembangan, pengujian, dan produksi konten independen. Informasi lebih lanjut di http://www.stainless-software.com/

[ad_2]

Source link

Leave a Reply

Your email address will not be published. Required fields are marked *