Advertisement
  1. Code
  2. BDD
Code

Memahami PhpSpec

by
Difficulty:AdvancedLength:LongLanguages:

Indonesian (Bahasa Indonesia) translation by Kaustina Nurul Ilmi (you can also view the original English article)

Jika anda membandingkan PhpSpec dengan kerangka pengujian lainnya, anda akan menemukan bahwa ini adalah alat yang sangat canggih dan berpendirian. Salah satu alasan untuk ini, adalah bahwa PhpSpec bukanlah kerangka pengujian seperti yang sudah anda ketahui.  

Sebaliknya, ini adalah alat perancangan yang membantu menggambarkan perilaku perangkat lunak. Efek samping dari mendeskripsikan perilaku perangkat lunak dengan PhpSpec, adalah anda akan berakhir dengan spesifikasi yang juga akan berfungsi sebagai tes setelahnya.

Pada artikel ini, kita akan melihat di kap PhpSpec dan mencoba untuk mendapatkan pemahaman yang lebih dalam tentang cara kerjanya dan cara menggunakannya.

Jika anda ingin memoles phpspec, lihatlah  getting started tutorial saya.

Dalam artikel ini ...

  • Sebuah Tour Cepat Dari PhpSpec Internal
  • Perbedaan Antara TDD dan BDD
  • Bagaimana PhpSpec berbeda (dengan PHPUnit)
  • PhpSpec: Alat Desain

Sebuah Tour Cepat Dari PhpSpec Internal

Mari kita mulai dengan melihat beberapa konsep dan kelas kunci yang membentuk PhpSpec.

Memahami $this

Memahami $this mengacu pada apada adalah kunci untuk memahami bagaimana PhpSpec berbeda dengan alat lainnya. Pada dasarnya,   $this mengacu pada contoh kelas yang sebenarnya saat diuji. Mari kita selidiki ini sedikit lebih banyak untuk lebih memahami apa yang kita maksud.

Pertama-tama, kita membutuhkan spec dan kelas untuk dimainkan. Seperti yang anda ketahui, generator PhpSpec membuatnya sangat mudah bagi kita:

Selanjutnya, buka file spec yang dihasilkan dan mari kita coba peroleh sedikit informasi lebih lanjut mengenai $this:

get_class () mengembalikan nama kelas dari objek yang diberikan. Dalam kasus ini, kita hanya melempar $this: di sana untuk melihat apa hasilnya:  

Oke, jadi tidak terlalu mengherankan,  get_class() memberitahu kita $this adalah sebuah instance dari spec\Suhm\HelloWorldSpec. Ini masuk akal karena, lagipula, ini hanya kode PHP tua biasa.  Jika kita pakai     get_parent_class (), kita akan mendapatkan PhpSpec\ObjectBehavior, karena spek kita memperluas kelas ini.

Ingat, saya baru saja memberitahu anda bahwa  $this sebenarnya disebut kelas yang diuji, yang akan menjadi Suhm\HelloWorld  dalam kasus kita? Seperti yang bisa anda lihat, nilai kembali  get_class($this) bertentangan dengan   $this-> shouldHaveType('Suhm\HelloWorld'); .

Mari kita coba yang lainnya:

Dengan kode diatas, kita coba memanggil metode bernama dumpThis() di instance HelloWorld.  Kita kaitkan ekspetasi untuk pemanggilan metode, mengharapkan nilai kembali fungsi menjadi string yang berisi "spec\Suhm\HelloWorldSpec". Ini adalah nilai kembali dari get_class() pada baris di atas

Sekali lagi, generator PhpSpec dapat membantu kita dengan beberapa perancah:

Mari kita coba memanggil  get_class() dari dalam dumpThis() juga: 

Sekali lagi, tidak mengherankan, kita mendapatkan:

Sepertinya kita melewatkan sesuatu di sini. Saya memulai dengan mengatakan $this tidak mengacu pada apa yang anda kira, tapi sejauh ini eksperimen kami tidak menunjukkan hal yang tidak terduga.  Kecuali satu hal: Bagaimana kita bisa memanggik $this->dumpThis()sebelum ia ada tanpa PHP mencicit pada kita?

Untuk memahami hal ini, kita perlu masuk lebih dalam ke kode sumber PhpSpec. Jika anda ingin melihatnya sendiri, anda bisa membaca kode pada GitHub .

Lihat kode berikut dari src/PhpSpec/ObjectBehavior.php (kelas yang spesifikasi kami perluas):

Komentar memberi sebagian besar: "Proxy semua panggilan ke subjek PhpSpec". PHP   __call   Metode adalah metode ajaib yang disebut secara otomatis setiap kali metode tidak dapat diakses (atau tidak ada).  

Ini berarti saat kita mencoba menelepon   $this->dumpThis() "Proxies all call to the PhpSpec subject". Jika anda melihat kode tersebut, anda dapat melihat bahwa metode panggilan diproklamasi  ke $this->object.  (Hal yang sama berlaku untuk properti di instance kami, semuanya juga diproklamasi dengan subjek, menggunakan metode magic lainnya. Lihatlah sumbernya untuk mengetahuinya)   

Mari kita berkonsultasi mengenai get_class() sekali lagi dan lihat apa yang harus dikatakannya  tentang $this->object:

Dan lihat apa yang kita dapatkan:

Lebih lanjut tentang Subyek

Subyek adalah pembungkus dan implementasi   PhpSpec\Wrapper\WrapperInterface. Ia adalah bagian inti dari PhpSpec dan memungkinkan semua magic [tampaknya] yang dapat dilakukan kerangka itu.  Ia membungkus sebuah instance dari kelas yang sedang kita uji, sehingga kita dapat melakukan bermacam hal seperti memanggil metode dan properti yang tidak ada dan menetapkan harapan.  

Seperti disebutkan, PhpSpec sangat berpendirian tentang bagaimana anda harus menulis dan menentukan kode anda. Satu spec peta untuk satu kelas. Anda hanya memiliki satu subjek per spec, yang PhpSpec akan bungkus dengan hati-hati untuk anda.  Yang penting untuk diperhatikan tentang hal ini adalah ia memungkinkan anda untuk menggunakan $this  seolah-olah ia adalah contoh sebenarnya dan membuat spesifikasi yang benar-benar dapat dibaca dan bermakna.

PhpSpec berisi Wrapper yang mengurus instantiating Subject. Ia membungkus Subject dengan objek yang sebenarnya kita spec'ing.  Karena Subject menerapkan  WrapperInterface, ia harus memiliki  metode  getWrappedObject() yang memberi kita akses ke objek. Ini adalah contoh objek yang kami cari sebelumnya dengan get_class ().  

Mari kita coba lagi:

Dan begitulah:

Meskipun banyak hal terjadi di balik layar, pada akhirnya kita masih bekerja dengan contoh objek sebenarnya Suhm\HelloWorld. Semua baik-baik saja. 

Sebelumnya, saat kita memanggil   $this-> dumpThis(), kita belajar cara panggilan diproksikan ke Subject. Kita juga belajar bahwa Subject hanya menjadi pembungkus dan bukan obyek aktual.  

Dengan pengetahuan ini, jelas bahwa kita tidak dapat memanggil dumpThis() di Subject tanpa metode magic lain. Subject mempunyai metode a __call() juga:

Metode ini melakukan satu dari dua hal. Pertama, ia memeriksa apakah nama metode dimulai dengan 'harus'.  Jika iaya, ini adalah sebuah ekspektasi, dan panggilan tersebut didelegasikan ke metode yang disebut  callExpectation(). Jika tidak, panggilan tersebut malah didelegasikan ke sebuah instance PhpSpec\Wrapper\Subject\Caller

Kita akan mengabaikannya Caller untuk sekarang. Iai juga berisi objek yang dibungkus dan tahu cara memanggil metode di atasnya.  Caller mengembalikan instance yang dibungkus saat ia memanggil metode pada subjek, memungkinkan kita untuk merancang ekspektasi terhadap metode, seperti yang kita lakukan dengan dumpThis ().

Sebagai gantinya, mari kita lihat metode callExpectation() :

Metode ini bertanggung jawab untuk membangun sebuah instance PhpSpec\Wrapper\Subject\Expectation\ExpectationInterface. Ia menentukan metode match() yang mana  callExpectation() dipanggil untuk memeriksa ekspektasi.  Ada empat macam ekspektasi:  PositiveNegativePositiveThrow dan NegativeThrow. Masing-masing ekspektasi ini berisi sebuah instance PhpSpec\Matcher\MatcherInterface yang metode match() gunakan Mari kita lihat matchers selanjutnya.

Matchers

Matchers adalah apa yang kita gunakan untuk menentukan tingkah laku objek kita. Kapan pun kita menulis  should... atau shouldnot..., kita menggunakan matcher. Anda dapat menemukan daftar matcher PhpSpec yang lengkap pada blog pribadi saya .

Ada banyak matchers disertakan dengan PhpSpec, yang semuanya memperluasu kelas PhpSpec\Matcher\BasicMatcher, yang menerapkan MatcherInterface.  Cara kerja matcher cukup lurus ke depan. Mari kita lihat bersama-sama dan saya dorong anda untuk melihat Kode sumber juga.

Sebagai contoh, mari kita lihat kode ini dari IdentityMatcher :

Metode supports() didikte oleh MatcherInterface. Dalam kasus ini, empat alias didefinisikan untuk matcher di array $keywords.  Ini akan memungkinkan matcher untuk mendukung shouldReturn()shouldBe()shouldEqual() atau shouldBeEqualTo(), atau shouldNotReturn()shouldNotBe()shouldNotEqual() atau shouldNotBeEqualTo().

Dari   BasicMatcher, dua metode yang diwarisi: positiveMatch() dan negativeMatch (). Mereka terlihat seperti ini:

Metode positiveMatch() melempar pengecualian jika metode matches() (metode abstrak yang harus diimplementasikan oleh matchers) kembali false. Metode negativeMatch() bekerja dengan cara yang berlawanan.  Metode matches()  untuk IdentityMatcher menggunakan  === operator untuk membandingkan  $subject dengan argumen yang diberikan pada metode matcher:

Kita bisa menggunakan matcher seperti ini:

Yang akhirnya akan memanggil  negativeMatch() dan pastikan matches() kembali false

Lihatlah beberapa matcher lainnya dan lihat apa yang mereka lakukan!

Janji lebih banyak magic

Sebelum kita akhiri tur singkat internal PhpSpec ini, mari kita lihat satu keajaiban lagi:

Dengan menambahkan tipe yang diisyaratkan parameter $object untuk contoh kita, PhpSpec akan otomatis menggunakan refleksi untuk memasukan sebuah instance dari kelas untuk kita gunakan.  Tapi dengan hal-hal yang kita lihat, apakah kita benar-benar percaya bahwa kita dapat sebuah contoh StdClass? Mari kita berkonsultasi get_class()sekali lagi:

Tidak. Dari pada StdClass, kita dapatkan sebuah instance PhpSpec\Wrapper\Collaborator. Tentang apakah ini? 

Seperti   SubjectCollaborator  adalah wrapper dan implementasi WrapperInterface. Ia membungkus instance \Prophecy\Prophecy\ObjectProphecy,yang berasal dari Prophecy, kerangka mocking yang datang bersama-sama dengan PhpSpec.  Daripada instance StdClass, PhpSpec memberi kita mock. Hal ini membuat mocking dengan mudah dengan PhpSpec dan memungkinkan kita menambahkan promises ke objek kita seperti ini:

Dengan tur singkat bagian-bagian internal PhpSpec ini, saya harap anda melihat bahwa ini lebih dari sekedar kerangka pengujian sederhana.

Perbedaan Antara TDD Dan BDD

PhpSpec adalah alat untuk melakukan SpecBDD, jadi untuk mendapatkan pemahaman yang lebih baik, mari kita lihat perbedaan antara test driven development (TDD) dan behavior driven development (BDD). Setelah itu, kita akan melihat sekilas bagaimana PhpSpec berbeda dengan alat lain seperti PHPUnit.

TDD merupakan konsep membiarkan pengujian otomatis menggerakkan disain dan implementasi kode. Dengan menulis tes kecil untuk setiap fitur, sebelum benar-benar menerapkannya, saat kita mendapatkan passing test, kita tahu bahwa kode kita memenuhi fitur spesifik itu.  Dengan passing test, setelah refactoring, kita berhenti melakukan coding dan menulis tes berikutnya. Mantra nya "merah", "hijau", "refactor"!

BDD berasal dari - dan sangat mirip dengan - TDD. Jujur, ini soal kata-kata, yang memang penting karena bisa mengubah cara kita berpikir sebagai pengembang. Dimana TDD berbicara tentang pengujian, BDD berbicara tentang mendeskripsikan perilaku.  

Dengan TDD, kitai fokus untuk memverifikasi bahwa kode kita sesuai dengan cara kita mengharapkannya bekerja, sedangkan dengan BDD, kita fokus untuk memverifikasi bahwa kode kita benar-benar sesuai dengan keinginan yang kita inginkan.  Alasan utama munculnya BDD, sebagai alternatif TDD, adalah untuk menghindari penggunaan kata "test". Dengan BDD, kita tidak terlalu tertarik untuk menguji penerapan kode kita, kita lebih tertarik untuk menguji apa yang dilakukannya (perilakunya).  Saat kita melakukan BDD, bukan TDD, kita memiliki cerita dan spesifikasi. Hal ini membuat penulisan tes tradisional berlebihan.

Cerita dan spesifikasi sangat terkait dengan harapan para pemangku kepentingan proyek. Menulis cerita (dengan alat seperti Behat), akan terjadi bersama-sama dengan para pemangku kepentingan atau ahli domain. Cerita-cerita tersebut mencakup perilaku eksternal.  Kami menggunakan spesifikasi untuk merancang perilaku internal yang diperlukan untuk memenuhi langkah-langkah cerita. Setiap langkah dalam sebuah cerita mungkin memerlukan banyak iterasi dengan spesifikasi penulisan dan penerapan kode, sebelum memuaskan.  Cerita kami, bersama dengan spesifikasi kami, membantu kami untuk memastikan bahwa bukan hanya kami yang sedang membangun hal yang berfungsi, tapi juga hal yang benar. Jadi, BDD banyak berhubungan dengan komunikasi.

Bagaimana PhpSpec Berbeda dengan PHPUnit?

Beberapa bulan yang lalu, anggota penting dari komunitas PHP, Mathias Verraes, memposting " Kerangka unit testing di tweet " di Twitter. Intinya sesuai dengan kode sumber kerangka pengujian unit fungsional menjadi satu tweet tunggal.  Seperti yang dapat anda lihat dari inti ini, kode ini benar-benar fungsional, dan memungkinkan anda menulis tes unit dasar. Konsep unit testing sebenarnya cukup sederhana: periksalah semacam pernyataan dan beri tahukan pengguna hasilnya.

Tentu saja, sebagian besar kerangka kerja pengujian, seperti PHPUnit, memang jauh lebih maju, dan dapat melakukan lebih dari sekadar kerangka kerja Mathias, namun tetap menunjukkan poin penting: anda menegaskan sesuatu dan kemudian kerangka anda menjalankan pernyataan itu untuk anda.

Mari kita lihat tes PHPUnit yang sangat mendasar:

Apakah anda bisa menulis sebuah implementasi super sederhana dari kerangka pengujian yang bisa menjalankan tes ini? Saya cukup yakin bahwa jawabannya adalah "iya" anda bisa melakukan itu.  Lagi pula, satu-satunya hal Metode assertTrue() harus lakukan adalah membandingkan nilai terhadap true  dan melemparkan pengecualian jika gagal. Intinya, apa yang sedang terjadi sebenarnya cukup lurus ke depan.

Jadi bagaimana PhpSpec berbeda? Pertama-tama, PhpSpec bukanlah alat pengujian. Menguji kode anda bukanlah tujuan utama PhpSpec, namun ini menjadi efek samping jika anda menggunakannya untuk merancang perangkat lunak anda dengan menambahkan spesifikasi untuk perilaku (BDD) secara bertahap.  

Kedua, saya pikir bagian di atas seharusnya sudah menjelaskan bagaimana PhpSpec berbeda. Namun, mari bandingkan beberapa kode:

Karena PhpSpec sangat berpendirian dan membuat beberapa pernyataan mengenai bagaimana kode kita dirancang, ini memberi kita cara yang sangat mudah untuk menggambarkan kode kita.  Di sisi lain, PHPUnit tidak membuat pernyataan apapun terhadap kode kita dan membiarkan kita melakukan cukup banyak apa yang kita inginkan. Pada dasarnya, semua PHPUnit melakukannya untuk kita dalam contoh ini, adalah untuk menjalankannya $object terhadap operator instanceof.   

Meskipun PHPUnit mungkin tampak lebih mudah untuk memulai (saya rasa tidak), jika anda tidak hati-hati, anda dapat dengan mudah terjebak dalam perangkap desain dan arsitektur yang buruk karena memungkinkan anda melakukan hampir semua hal.  Bisa dikatakan, PHPUnit masih bisa menjadi hebat untuk banyak kasus penggunaan, namun ini bukan alat desain seperti PhpSpec. Tidak ada panduan - anda harus tahu apa yang anda lakukan.

PhpSpec: Alat Desain

Dari Situs PhpSpec, kita dapat belajar bahwa PhpSpec adalah:

Alat bantu php untuk mengemudikan desain yang muncul dengan spesifikasi.

Izinkan saya mengatakannya sekali lagi: PhpSpec bukanlah kerangka pengujian. Ini adalah alat pengembangan. Alat perancang perangkat lunak. Ini bukan kerangka pernyataan sederhana yang membandingkan nilai dan membuang pengecualian.  Ini adalah alat yang membantu kita dalam merancang dan membangun kode yang dibuat dengan baik. Ia mengharuskan kita untuk memikirkan struktur kode kita dan menerapkan pola arsitektur tertentu, di mana satu peta kelas menjadi satu spec.  Jika anda melanggar prinsip tanggung jawab tunggal dan perlu melakukan mock sesuatu, anda tidak akan diizinkan melakukannya.

Selamat spec'ing!

Oh! Dan akhirnya, = karena PhpSpec sendiri adalah spec'ed, saya sarankan anda pergi ke GitHub dan  mengeksplorasi sumber untuk mempelajari lebih lanjut .

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.