Praktik Terbaik untuk Pengujian Regresi Situs Web WordPress?

Halo semua,

Saya ingin mendengar apa yang orang lain yang memberikan solusi non-blog kompleks untuk klien dengan WordPress sebagai platform apa yang mereka gunakan untuk Pengujian Regresi otomatis ?

Bagi mereka yang tidak terbiasa dengan istilah "pengujian regresi" Wikipedia mendefinisikannya sebagai:

Pengujian regresi adalah segala jenis pengujian perangkat lunak yang berupaya mengungkap kesalahan perangkat lunak setelah perubahan pada program (misalnya perbaikan bug atau fungsi baru) telah dilakukan, dengan menguji ulang program. Maksud pengujian regresi adalah untuk memastikan bahwa perubahan, seperti perbaikan bug, tidak memperkenalkan bug baru.

Wikipedia mengatakan lebih banyak tentang hal-hal berikut yang persis apa yang saya alami pada sebuah proyek saat ini:

Pengalaman menunjukkan bahwa ketika perangkat lunak diperbaiki, kemunculan kesalahan baru dan / atau timbul kembali kesalahan lama adalah hal yang biasa. Kadang-kadang muncul kembali karena perbaikan hilang melalui praktik kontrol revisi yang buruk (atau kesalahan manusia sederhana dalam kontrol revisi). Seringkali, perbaikan untuk masalah akan "rapuh" karena memperbaiki masalah dalam kasus yang sempit di mana ia pertama kali diamati tetapi tidak dalam kasus yang lebih umum yang mungkin muncul selama masa pakai perangkat lunak. Seringkali, perbaikan untuk masalah di satu area secara tidak sengaja menyebabkan bug perangkat lunak di area lain. Akhirnya, sering terjadi bahwa ketika beberapa fitur didesain ulang, beberapa kesalahan yang sama yang dibuat dalam implementasi asli fitur dibuat dalam desain ulang.

Dengan sifat global dari tindakan dan filter, saya menemukan bahwa kompleksitas mulai meningkat ketika saya menambahkan lebih banyak fungsi yang diminta klien dan menjadi sulit untuk mendapatkan stabil plugin yang kompleks, terutama jika ia menggunakan banyak panggilan ke WP_Querydan memperbarui database banyak. .

Solusi dalam pikiran saya adalah mengatur pengujian regresi dengan serangkaian "test case" untuk membentuk "test suite." Dalam konsepnya tidaklah sulit ketika Anda menguji output HTML dari permintaan GET HTTP. Tapi itu menjadi sedikit lebih rumit ketika Anda harus menguji hal-hal ketika masuk melalui konsol admin dan / atau untuk menguji interaksi jQuery.

Saya menyiapkan ini sebagai wiki komunitas dengan harapan kami dapat mengumpulkan praktik terbaik di sini, tetapi saya benar-benar ingin mendengar proses jika ada profesional WordPress lain yang menggunakan.

PHPUnit akan muncul dalam pikiran, jika WP test suite tidak begitu rusak, dan jika WP telah dirancang dan ditulis dengan cara yang benar-benar dapat diuji dengan benar. ;-)

Lebih serius, Anda dapat menguji plugin Anda semua yang Anda inginkan dari sudut pandang fungsional mereka dengan unit test dan sejenisnya. Masalahnya adalah bahwa tes ini tidak akan menjamin bahwa mereka akan menangkap peluang halus yang diperkenalkan oleh peningkatan WP, apalagi bahwa mereka akan terus bekerja setelah dicolokkan ke instalasi WP yang disesuaikan.

Di antara hal-hal penuh warna yang pernah saya lihat terjadi:

• Perubahan halus di WP API memengaruhi fungsionalitas plugin Anda, mis. Hook yang Anda gunakan untuk mendapatkan term id dan sekarang mendapatkan term taxonomy id. (Kemungkinannya bagus bahwa istilah pengujian Anda memiliki id yang sama untuk keduanya).

• Perubahan halus dalam WP API menghasilkan Anda menerima WP_Errorobjek bukannya nilai yang diharapkan sebelumnya falsesebagai input buruk.

• Plugin Anda ditambahkan dari dalam folder mu-plugins, menghasilkan aliran kode yang sedikit berbeda.

• Plugin Anda berfungsi dengan baik sampai memcached atau beberapa toko persisten lainnya diaktifkan.

• Plugin Anda berfungsi dengan baik sampai switch_to_blog () yang dihina dipanggil.

• Sebuah plugin mengubah pengait yang berada di tempatnya ketika dipanggil, dan tanpa sadar menginterupsi sebagai efek samping.

• Sebuah plugin (tidak?) Dengan sengaja mengacaukan input atau output data Anda ke titik di mana segala sesuatu tampak rusak meskipun Anda tidak bersalah.

Saya dapat memperluas daftar terus dan terus, tetapi itu akan menjadi item kunci yang merusak plugin saya sendiri. Kedua item ini bisa dibilang bisa ditangkap dengan tes unit. Dua berikutnya juga, jika Anda cukup sabar, tapi saya berpendapat bahwa WP seharusnya tidak mengubah cara kerja ketika mereka terjadi. Tidak ada jumlah pengujian yang akan bekerja di sekitar implementasi buggy dari switch_to_blog (). Dan dua yang terakhir adalah tanpa harapan yang tidak dapat diuji.

Oh, dan ... bahkan tidak memulai saya dengan serangan lampiran, konsep otomatis, revisi, item menu dan apa yang tidak berakhir disimpan di tabel posting.

Semoga berhasil... :-)

Anda harus sangat mempertimbangkan Selenium .

Ini memungkinkan Anda untuk merekam tindakan (misalnya memasukkan data ke dalam formulir, mengklik tautan) dan kemudian Anda dapat melakukan pernyataan. Ini juga terintegrasi dengan PHPUnit. Saya sangat merekomendasikan memeriksa demo dua menit.

Selenium mungkin dapat digunakan tetapi saya pikir di zaman modern ini Anda akan menemukan Codeception menjadi lebih baik dan lebih mudah digunakan. Untuk pengujian regresi visual paling sederhana, bahkan memiliki ekstensi yang akan mengambil tangkapan layar dan secara otomatis membandingkannya untuk Anda.

Tentu saja, tes Codeception WebDriver dapat melangkah lebih jauh dan melakukan tes regresi fungsional . Anda dapat mengisi dan mengirimkan formulir, mengklik tombol dan tautan di situs, menjalankan JS apa pun, dll. Anda dapat menggunakan browser kehidupan nyata seperti Firefox atau Chrome dalam pengujian Anda, atau Anda dapat melakukan pengujian tanpa kepala dengan PhantomJS . Itu berarti Anda bahkan dapat menjalankan tes WebDriver untuk plugin Anda sebagai bagian dari proses pembuatannya di Travis CI jika Anda mau.

Bahkan ada beberapa perpustakaan khusus WordPress untuk membantu Anda memulai:

• WP Browser
• WP Codeception