Advertisement
  1. Code
  2. Web Development

Refactoring Legacy Code: Bagian 4 - Unit Test Pertama

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called Refactoring Legacy Code.
Refactoring Legacy Code: Part 3 - Complex Conditionals
Refactoring Legacy Code: Part 5 - Game's Testable Methods

Indonesian (Bahasa Indonesia) translation by Arief Syahrir (you can also view the original English article)

Refactoring Legacy Code: Bagian 4 - Unit Test Pertama

Kode lama. Kode jelek. Kode yang rumit. Kode spaghetti. Omong kosong . Dalam 2 kata, Legacy code. Ini adalah seri yang akan membantu Anda bekerja dan berurusan dengan itu.

Salah satu saat-saat penting dari refactoring legacy code adalah ketika kita mulai mengeluarkan potongan-potongan kecil dari itu dan kita mulai menulis unit test untuk potongan-potongan kecil yang ditargetkan. Tapi ini bisa sangat sulit, terutama ketika Anda memiliki kode yang ditulis sehingga akan sulit untuk mengkompilasi atau menjalankan jika potongan-potongan itu hilang. Kita tidak dapat dengan aman melakukan besar operasi pada kode kita masih hampir tidak mengerti dan hanya golden master tes membuat kita melanggar itu benar-benar. Untungnya ada beberapa teknik yang dapat membantu kita.

Apa itu Unit Test?

Sepanjang sejarah pengujian otomatis, dua puluh tahun atau lebih, istilah Unit Test didefinisikan dalam banyak cara. Awalnya itu adalah tentang cakupan kode etik dilaksanakan dalam tes. Unit test adalah tes yang diuji unit mungkin terkecil dari bahasa pemrograman tertentu.

Dalam pengertian ini, untuk kode PHP, unit test adalah tes yang melatih satu fungsi atau metode. Ketika kami pemrograman objeck oriented style, fungsi kita diatur dalam class. Semua tes yang terkait dengan sebuah keclasslas tunggal biasanya disebut Test Case.

Ada sekitar 25 definisi lain untuk istilah Unit Test, jadi kita tidak akan pergi ke masing-masing. Sementara definisi ini sangat berbeda, mereka semua memiliki dua hal kesamaan. Ini membawa kita ke definisi yang mungkin paling diterima.

Unit Test adalah tes yang berjalan dalam milidetik dan tes sepotong kode dalam isolasi.

Kita harus mencatat dua kata kunci dalam definisi: milidetik - pengujian kami harus berjalan cepat, sangat cepat; dan isolasi - kita harus menguji kode kita sebagai terisolasi sebanyak mungkin. Dua kata kunci ini pergi hand-in-hand, karena untuk membuat tes lebih cepat kita harus mengurangi jangkauan. Database, jaringan komunikasi, user interface, mereka terlalu lambat untuk diuji dengan cara ini. Kita perlu menemukan dan mengisolasi kecil cukup potongan kode, sehingga kita dapat mengkompilasi (jika diperlukan) dan menjalankan bahwa kode dalam milidetik, yaitu dalam kurang dari sepuluh milidetik, karena itu akan menjadi centisecond. Framework tes kami akan menambahkan sedikit overhead selama jangka waktu murni kode, tapi itu diabaikan.

Mengidentifikasi kode untuk Unit Test

Mencari metode terisolasi

Jika memungkinkan struktur kode, dianjurkan untuk memulai dengan menulis tes untuk kode apa pun kita benar-benar dapat menguji. Ini akan membantu kami mulai membangun cakupan dan juga akan memaksa kita untuk berkonsentrasi dan memahami potongan kecil kode. Ingat, kita refactoring, kita tidak ingin mengubah perilaku. Bahkan, pada langkah ini awal kita tidak ingin mengubah kode produksi kami di semua jika mungkin.

Kita perlu menganalisis tiga file, untuk melihat apa yang kita dapat menguji dan apa yang tidak.

GameRunner.php pada dasarnya tidak memiliki logika. Kita diciptakan untuk menjadi hanya sebuah delegasi. Bisa kami menguji it? Yakin kita bisa. Kita harus mengujinya? Tidak, kita seharusnya tidak. Meskipun beberapa metode dapat, dalam pengertian teknis, diuji, jika tidak ada logika di dalamnya kami mungkin tidak ingin menguji mereka.

RunnerFunctions.php adalah cerita yang berbeda. Ada dua fungsi di sana. run() adalah fungsi besar, melakukan secara keseluruhan menjalankan sistem. Ini bukanlah sesuatu yang kita dapat dengan mudah menguji. Dan itu tidak memiliki nilai kembalian, itu hanya output ke layar, sehingga kita harus menangkap output dan membandingkan string. Hal ini tidak sangat khas untuk Unit Testing. Di sisi lain isCurrentAnswerCorrect() mengembalikan nilai true atau false didasarkan pada beberapa kondisi. Kita dapat menguji itu?

Kita sudah mengerti bahwa kode ini menghasilkan nomor acak dan membandingkannya dengan ID nomor yang salah.

Langkah 1 - pergi ke GoldenMasterTest.php dan Tandai semua tes sebagai dilewati. Kami tidak ingin menjalankan mereka untuk sementara waktu. Ketika kita mulai membangun unit test, kami akan menjalankan golder msater lebih jarang. Seperti kita menulis tes baru dan kita tidak memodifikasi kode produksi, cepat umpan balik lebih penting.

Langkah 2 - membuat tes baru RunnerFunctionsTest.php dalam direktori Test kami, bersama GoldenMasterTest.php. Sekarang pikir tentang kode mungkin tes sederhana bahwa Anda dapat menulis. Apa itu minimal untuk mendapatkannya berjalan? Yah, itu adalah sesuatu seperti ini:

Kami membutuhkan RunnerFunctions.php file, jadi kami menguji bahwa dapat dimasukkan dan tidak menghasilkan kesalahan. Sisanya kode adalah boilerplate murni, hanya sebuah kerangka class dan fungsi tes yang kosong. Tapi, sekarang apa? Apa yang kita lakukan selanjutnya? Apakah Anda tahu bagaimana kita dapat trik rand() untuk mengembalikan yang kita inginkan? Aku tidak tahu, belum. Jadi mari kita menyelidiki bagaimana itu bekerja sekarang.

Kita tahu bagaimana seed generator acak, jadi apa jika kita mencoba untuk seed itu dengan beberapa nomor, itu bekerja? Kita dapat menulis kode dalam pengujian kami untuk mencari tahu bagaimana sesuatu bekerja.

Kita juga tahu bahwa kami id pertanyaan antara nol dan sembilan. Hal ini menghasilkan output di bawah ini.

Yah, itu tidak terlihat sangat jelas. Bahkan saya bisa melihat ada logika tentang bagaimana kami dapat menentukan nilai-nilai fungsi rand() akan menghasilkan. Kita akan perlu untuk memodifikasi kode produksi kami, sehingga kami dapat menyuntikkan nilai-nilai yang kita butuhkan.

Dependensi dan Dependecy Injection

Ketika kebanyakan orang berbicara tentang "dependecy" mereka berpikir tentang hubungan antara class. Ini adalah kasus yang paling umum, terutama dalam pemrograman berorientasi objek. Tapi bagaimana jika kita generalisasi istilah sedikit. Lupakan tentang class, lupa tentang objek, berkonsentrasi hanya pada arti dari "dependecy". Apa metode rand(min,max) kami bergantung? Itu tergantung pada dua nilai. Minimum dan maksimum.

Dapat kami kontrol rand() oleh dua parameter tersebut? Tidak rand() diduga mengembalikan nomor yang sama jika min dan maks yang sama? Mari kita lihat.

Jika kita benar, setiap baris harus membuang beberapa dari nol sampai empat cara yang dapat diprediksi.

Yang terlihat cukup bisa diprediksi kepadaku. Dengan mengirimkan sama jumlah min dan maks untuk rand() kita dapat yakin kita menghasilkan jumlah yang diharapkan. Sekarang, bagaimana kita melakukan ini untuk fungsi kita? Itu tidak memiliki parameter!

Mungkin cara yang paling umum untuk menyuntikkan dependensi ke metode adalah dengan menggunakan parameter dengan nilai default. Ini akan menjaga fungsi yang saat ini fungsi, tetapi akan memungkinkan kita untuk mengontrol aliran ketika kami mengujinya.

Memodifikasi isCurrentAnswerCorrect() cara ini akan melestarikan its perilaku saat ini dan memungkinkan kita untuk menguji pada waktu yang sama. Anda dapat mengaktifkan ulang tgolder master dan menjalankannya sekarang. Kode produksi berubah, kita perlu untuk memastikan kita tidak memecahkannya.

Seperti isCurrentAnswerCorrect() kami terlihat sekarang, pengujian itu adalah hanya masalah mengirim sepuluh nilai untuk setiap nomor mungkin yang dikembalikan oleh rand().

Tes fungsi dibangun dengan menjalankan pengujian kami setelah setiap baris. Sekarang bahwa pengujian kami sangat cepat, kita dapat menjalankan mereka hampir terus menerus. itu benar-benar tool untuk menjalankan tes segera setelah perubahan file dan aku sudah mendengar tentang programmer yang menjalankan tes mereka terus-menerus dan mereka hanya melihat sekilas di bilah status uji pada akhir setiap perintah. Seperti yang Anda program Anda tahu apa yang diharapkan, jika tes tidak berubah hijau bila Anda pikir seharusnya, Anda melakukan sesuatu yang salah. Mereka melihat umpan balik begitu ketat, ianya hampir kepastian bahwa sesuatu yang tidak beres di baris terakhir atau perintah mereka tulis.

Walaupun itu mungkin terdengar ekstrim test driven development, saya membayangkan hal ini berguna terutama ketika Anda mengembangkan algoritma. Saya pribadi lebih suka untuk menjalankan tes dengan menekan pintasan, pintasan tombol tunggal. Dan seperti tes yang membantu saya mengembangkan program saya, saya shortcut untuk menjalankan tes F1.

Mari kita kembali ke bisnis kami. Tes itu, dengan sepuluh assertion, berjalan di ms 66, sekitar 6.6 ms per assertion. Setiap assertion panggilan dan mengeksekusi sepotong kode kita. Hal ini tampaknya seperti kita didefinisikan unit test pada awal tutorial ini.

Apakah Anda melihat assertFalse() untuk nomor tujuh? Aku bertaruh setengah dari Anda melewatkannya. Ia dikuburkan dalam sekelompok pernyataan lain. Sulit untuk tempat. Saya pikir layak tes sendiri, jadi kami membuat eksplisit kasus satu jawaban yang salah.

Refactoring tes

Seperti kita dalam pencarian dari refactoring, membuat kode lebih baik, lebih mudah untuk memahami, kita tidak boleh lupa tentang pengujian kami. Mereka sama pentingnya dengan kode produksi kami. Kita perlu untuk menjaga tes kitabersih dan mudah untuk memahami juga. Kita perlu refactor pengujian kami dan kami harus melakukannya segera kita mengamati sesuatu salah dengan mereka dan hanya ketika mereka sukses. Dengan cara ini, kode produksi dapat memverifikasi pengujian kami. Jika kita memiliki tes hijau, kita refactor itu dan berubah merah, kita melanggar tes. Kita hanya dapat membatalkan beberapa langkah dan coba lagi.

Kita bisa ekstrak nomor jawaban yang benar ke dalam array dan menggunakannya untuk menghasilkan jawaban yang benar.

itu sukses, tetapi juga memperkenalkan beberapa logika. Mungkin kita bisa ekstrak dalam kustom assertion. Ini mungkin sedikit ekstrim untuk sebuah tes sederhana, tetapi itu adalah kesempatan yang baik untuk memahami konsep.

Sekarang, ini membantu kami dalam dua cara. Pertama, kami pindahkan logika tentang pergi ke setiap elemen array memeriksanya ke metode private. Karena kita biasanya tetap metode private kami pada akhir class, dari pandangan, keluar dari cara logika tingkat lebih tinggi dalam metode umum, kami berhasil naik abstraksi dari pengujian kami. Dalam metode pengujian kami tidak peduli tentang bagaimana jawaban diverifikasi untuk kebenaran. Kita peduli tentang id yang harus mewakili jawaban yang benar. Keuntungan kedua adalah melanggar implementasi dari persiapan. Menjaga jawaban yang benar id dalam tes membantu kami memisahkan rincian implementasi dari premis yang kita perlu untuk menguji.

Tes untuk produksi kode dependensi

Salah satu yang paling umum kesalahan kita komit saat menulis ujian adalah mengulang apa yang ada dalam kode produksi. Ini adalah kasus duplikasi kode dan ketergantungan tersembunyi, biasanya pada beberapa nilai atau konstanta. Dalam kasus kami ketergantungan adalah pada ID jawaban yang mewakili jawaban yang salah.

Tapi bagaimana untuk membuktikan ketergantungan ini? Pada pandangan pertama tampaknya hanya duplikasi sederhana single valye. Untuk menjawab dilema Anda bertanya pada diri sendiri pertanyaan ini: "Haruskan tesnya gagal jika saya memutuskan untuk mengubah ID jawabannya salah?". Tentu jawabannya adalah tidak. Mengubah konstanta sederhana dalam kode produksi tidak akan mempengaruhi perilaku, atau logika. Dengan demikian, tes jangan gagal.

Kedengarannya hebat! Tetapi bagaimana melakukannya? Yah, cara paling sederhana adalah hanya untuk mengekspos variabel yang diinginkan sebagai variabel kelas public, lebih baik statis atau konstan. Dalam kasus kami, karena kami memiliki class tidak ada, kita dapat hanya membuat variabel global atau konstan.

Pertama memodifikasi RunnerFunctions.php file sehingga isCurrentAnswerCorrect() akan menggunakan konstan bukan variabel lokal. Kemudian jalankan unit tes. Hal ini menjamin kita bahwa perubahan yang kami buat untuk kode produksi tidak memecahkan sesuatu. Sekarang saatnya untuk menguji.

Memodifikasi testItCanFindWrongAnswer() menggunakan yang sama terus-menerus. Seperti file RunnerFunctions.php disertakan pada awal file tes, yang terus-menerus menyatakan akan dapat diakses oleh tes.

Refactoring tes (lagi)

Sekarang, bahwa kita bergantung pada WRONG_ANSWER_ID untuk testItCanFindWrongAnswer() kami, tidak boleh kita refactor pengujian kami sehingga testItCanFindCorrectAnswer() juga mengandalkan konstan sama? Juga kita harus. Itu tidak hanya akan membuat tes kami lebih mudah untuk memahami, itu juga akan membuat lebih kuat. Ya, karena jika kita memilih ID jawaban salah yang sudah di daftar jawaban yang benar didefinisikan dalam tes, hal tertentu akan menjadi test yang gagal meskipun kode produksi masih akan benar.

Sementara memiliki angka-angka untuk jawaban yang benar dalam fungsi tes itu sendiri adalah ide yang baik di beberapa titik, ketika kita berubah pengujian kami untuk lebih dan lebih bergantung pada nilai-nilai yang diberikan oleh kode produksi, kami juga ingin menyembunyikan rincian tentang angka. Langkah pertama adalah untuk menerapkan metode ekstrak refactoring dan mendapatkannya dalam metode sendiri.

Kami mengubah getGoodAnswerIDs() secara signifikan. Pertama-tama kita menghasilkan daftar dengan range() mengetik semua mungkin id dengan tangan. Kemudian kita kurangi dari array elemen yang mengandung WRONG_ANSWER_ID. Sekarang daftar jawaban yang benar id juga independen dari nilai yang ditetapkan dalam id jawaban yang salah. Tapi apakah itu cukup? Bagaimana dengan minimum dan maksimum id? Tidak bisa kita ekstrak mereka juga dengan cara yang sama? Yah, mari kita lihat.

Hal ini terlihat cukup bagus. Konstanta hanya digunakan sebagai nilai default untuk parameter fungsi isCurrentAnswerCorrect(). Hal ini masih memungkinkan kita untuk menyuntikkan nilai yang diperlukan ketika pengujian dan juga membuat sangat jelas maksud parameter-parameter tersebut. Sebagai efek samping yang baik, satu blok kecil konstanta di bagian atas dari file mulai menyoroti nilai-nilai kunci yang menggunakan file RunnerFunctions.php kami. Bagus!

Hanya jangan lupa untuk mengaktifkan kembali dari golder master tes testOutputMatchesGoldenMaster() fungsi. Konstanta kami memperkenalkan digunakan hanya dalam golder master tes. Unit kami tes benar-benar pintas nilai-nilai tersebut selalu.

Sekarang kita perlu untuk memperbarui unit tes menggunakan konstanta.

Itu sederhana dan mudah. Kami hanya harus mengubah parameter ke metode range().

Langkah terakhir yang bisa kita lakukan dengan tes kami, adalah untuk membersihkan kekacauan kami tertinggal di metode testItCanFindCorrectAnswer() kami.

Kita dapat mengamati dua masalah besar dengan kode ini. Pertama inkonsistensi di penamaan. Sekali kita disebut jawaban yang benar dan kemudian kami memanggil mereka baik. Kita harus memutuskan pada salah satu dari dua. Benar tampaknya menjadi tata bahasa lebih pas. Sebagai benar adalah kebalikan dari salah, sementara baik adalah lawan dari buruk.

Kami mengganti nama metode kami private sesuai dengan alasan di atas. Tapi itu tidak cukup. Kita perlu untuk memecahkan masalah lain. Kami menetapkan nilai kembali metode private untuk variabel hanya untuk menggunakan variabel yang sama di baris berikutnya. Dan ini adalah satu-satunya kasus penggunaan untuk variabel. Dalam kasus kami, variabel yang ada karena itu diberikan tambahan penjelasan tentang apa yang dimaksudkan array nomor. Itu yang digunakan dan cakupan. Tapi sekarang bahwa kita memiliki sebuah metode dengan hampir nama yang sama, mengungkapkan konsep yang sama, variabel outlived kegunaan nya. Ini adalah tugas yang tidak perlu.

Kita dapat menggunakan variabel inline refactoring untuk menghapus variabel dan memanggil metode langsung daripada menggunakan variabel pada baris berikutnya.

Sekarang, apakah benar-benar keren di sini adalah bahwa kita mulai dengan hanya dua baris kode yang tidak jelas dan itu sudah tercemar oleh duplikasi dan ketergantungan tersembunyi. Setelah beberapa langkah perubahan kita berakhir dengan dua baris kode juga, tapi kita melanggar ketergantungan pada nomor ID numerik. Apakah itu keren atau apa?

Melanggar Run

Kami selesai dengan RunnerFunctions.php? Baik jika aku melihat if() yang berarti logika. Jika saya melihat logika yang berarti unit test yang dibutuhkan untuk memverifikasi itu. Dan kami memiliki if() dalam metode run() kami do-while() loop. Saatnya untuk menggunakan IDE kami refactoring tool untuk mengekstrak metode dan kemudian mengujinya.

Tapi apa bagian dari kode yang harus kita ekstrak? Pada pandangan pertama mengambil hanya pernyataan bersyarat tampaknya ide yang baik. Ini mengarah ke kode di bawah ini.

Sementara ini terlihat cukup layak dan dibuat dengan hanya memilih item menu kanan dari IDE kami, ada masalah yang mengganggu saya. Objek aGame digunakan baik di do-while loop dan baik dalam metode diekstrak. Bagaimana dengan ini?

Solusi ini menghapus objek aGame dari loop. Namun ini memperkenalkan jenis masalah. Meningkatkan jumlah parameter kami. Sekarang kita perlu mengirim dalam $dice. Sementara jumlah semata-mata parameter, dua, cukup rendah untuk tidak bangkit kekhawatiran kita juga harus berpikir tentang bagaimana parameter yang digunakan dalam metode itu sendiri. $dice hanya digunakan ketika roll() metode ini disebut pada aGame. Sementara metode roll() memiliki signifikansi yang besar dalam class Game, hal ini tidak salah satu yang memutuskan jika kita memiliki pemenang atau tidak. Dengan menganalisis kode dalam Game, kita dapat menyimpulkan bahwa keadaan pemenang dapat triue hanya dengan memanggil wasCorrectlyAnswered(). Ini aneh dan menyoroti beberapa masalah penamaan yang serius dalam class Game kami akan alamatkan ini di pelajaran berikutnya.

Berdasarkan semua pengamatan di atas, paling mungkin lebih baik untuk pergi dengan versi pertama dari metode kami diekstrak.

Kita bisa percaya dalam IDE kami dan dengan hanya melihat kode kita dapat cukup yakin tidak rusak. Jika Anda merasa tidak yakin, hanya menjalankan golder master tes. Sekarang mari kita fokus pada menciptakan beberapa tes untuk metode yang bagus ini.

Saya datang dengan nama ini dengan mengubah apa yang saya ingin menguji ke nama metode pengujian. Hal ini sangat penting untuk nama tes Anda tentang perilaku apa yang mereka harus menguji dan tidak tentang apa yang akan mereka lakukan. Ini akan membantu orang lain atau diri Anda sendiri enam bulan dari sekarang, untuk memahami apa itu potongan kecil kode harus benar-benar melakukan.

Tapi kita memiliki masalah. Metode kami diuji membutuhkan objek. Kita harus menjalankannya seperti ini:

Kita perlu $aGame objek jenis Game. Tapi kita melakukan tes unit, kami tidak ingin menggunakan class asli, kompleks dan sangat dipahami, Game class. Hal ini membawa kita ke babak baru dalam pengujian, kita akan berbicara tentang pada pelajaran yang lain: Mocking, Stubbing dan Faking. Berikut adalah semua teknik untuk membuat dan menguji objek dengan menggunakan objek lain yang berperilaku dengan cara yang standar. Sementara menggunakan framework atau bahkan sendiri PHPUnit built-in kemampuan dapat membantu, untuk pengetahuan kita saat ini untuk tes kami sangat sederhana kita dapat melakukan hal yang banyak orang lupa.

Kita dapat membuat sebuah class mirip dengan Game di dalam file pengujian kami dan mendefinisikan itu hanya dua metode kami tertarik. Hal ini sangat sederhana.

Hal ini membuat kami tes lulus dan kami masih di zona milidetik. Catatan bahwa dua tes yand dilewatkan adalah dari golder master.

Meskipun kita harus nama class kami berbeda dari Game karena kami tidak menyatakan class yang sama dua kali, kode cukup sederhana. Kami hanya mendefinisikan dua metode kami tertarik. Langkah berikutnya adalah untuk benar-benar mengembalikan sesuatu dan menguji untuk itu. Tapi ini mungkin lebih sulit daripada yang kita diharapkan karena baris kode ini:

Metode kita memanggil isCurrentAnswerCorrect() tanpa parameter. Ini buruk bagi kita. Kita tidak dapat mengendalikan outputnya. Ini hanya akan menghasilkan angka acak. Kita perlu refactor kode kami sedikit sebelum kita dapat melanjutkan. Kita perlu untuk memindahkan panggilan metode ini ke loop dan memasukan hasilnya sebagai parameter ke getNotWinner(). Ini akan memungkinkan kita untuk mengontrol hasil ekspresi dalam jika di atas if statement, dengan demikian mengontrol jalur dimana kode kita akan turun. Untuk pengujian kami pertama kita perlu untuk memasukkan jika dan memanggil wasCorrectlyAnswered().

Sekarang kita memiliki kontrol, semua dependensi yang rusak. Saatnya untuk pengujian.

Ini adalah tes yang sukses, cukup bagus. Kami mengembalikan true dari metode ditimpa kami, tentu saja.

Kita perlu menguji jalur lain melalui if() juga.

Kami hanya memilih untuk menguji false saat ini, jadi kita membedakan antara dua kasus lebih mudah.

Dan FakeGame kami diubah sesuai.

Pembersihan akhir

Refactoring metode yang diekstraksi

Kita hampir selesai. Maaf untuk mendapatkan tutorial ini begitu lama, saya harap Anda menyukainya dan tidak ketiduran. Perubahan terakhir sebelum menutup RunnerFunctions.php file dan tes nya.

Ada beberapa tugas yang tidak perlu dalam metode kami, kita harus membersihkannya. Unit kami tes akan membuat perubahan ini sangat aman.

Kami diterapkan refactoring inline variabel sama dan itu menyebabkan menghilang. Tes masih melewati dan kita yang masih di bawah 100 ms untuk semua unit test bersama-sama. Saya mengatakan ini cukup bagus.

Refactoring tes (lagi, lagi)

Ya, ya, kita dapat membuat tes kami sedikit lebih baik juga. Karena kita hanya memiliki beberapa baris kode, refactorings kami akan mudah. Masalahnya adalah dalam kode di bawah ini.

Kami telah duplikasi kode dengan memanggil FakeGame() baru dalam setiap metode. Waktu untuk mengekstract metode.

Sekarang,membuat variabel $aGame cukup tidak berguna. Waktu untuk variabel inline.

Hal ini membuat kode kita lebih pendek dan lebih ekspresif pada waktu yang sama. Saat kita membaca assertion bunyinya seperti prosa. Menegaskan bahwa kita menerima true yang kita sebut mencoba untuk mendapatkan tidak pemenang menggunakan class fake dengan benar jawaban yang disediakan. Apa yang saya masih tidak suka adalah bahwa kita menggunakan variabel yang sama dan menetapkan itu true atau false tergantung pada tes. Saya pikir harus ada cara yang lebih ekspresif untuk melakukannya.

Wow! Pengujian kami menjadi satu liners dan mereka benar-benar menyatakan apa yang kami uji. Semua rincian yang tersembunyi dalam metode private, pada akhir tes. 99% dari kasus-kasus yang Anda tidak akan peduli tentang implementasi mereka dan ketika Anda melakukannya, Anda dapat hanya CTRL + klik pada nama metode dan IDE akan melompat ke implementasi.

Kembali ke kode produksi

Jika kita melihat lingkaran kami, kita dapat melihat bahwa ada sebuah variabel yang kita dapat menyingkirkan dalam sekejap mata.

Yang akan berubah menjadi ini:

Bye, bye $notAWinner variabel. Tapi nama metode kami mengerikan. Kita tahu kita harus selalu lebih suka penamaan positif dan perilaku dan meniadakan itu diperlukan conditional. Apa tentang penamaan ini?

Tetapi dengan nama itu, kita perlu untuk meniadakan di while() dan mengubah perilaku juga. Kita mulai dengan mengubah pengujian kami.

Benar-benar mengubah hanya fake game lebih baik. Itu membuat tes benar-benar mudah dibaca, dengan nama metode baru.

Mendapatkan tes menjadi sukses

Tentu tes gagal sekarang. Kita harus mengubah metode implementasi.

Memperbaiki Golden Master

Unit test sukses, tetapi menjalankan Golder master akan error. Kita perlu untuk meniadakan login di while statement.

Selesai!

Sekarang yang membuat golder master sukses lagi dan kami do-while berbunyi seperti ditulis prosa juga dengan baik. Sekarang sudah benar-benar waktu untuk berhenti. Terima kasih sudah membaca.

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.