Tiga aturan mengatur Test-Driven Development (TDD). Aturan pertama menegaskan, 'Hanya tulis kode produksi agar pengujian unit gagal lulus. '. Di sini kita memiliki prinsip utama TDD - bahwa kita menunda penulisan kode perilaku, kita memiliki unit test yang menuntut perilaku tersebut. Dan tes ini pasti gagal. Baru setelah itu kita lulus pengujian dengan menciptakan perilaku yang sesuai dalam kode implementasi.

Seringkali, cukup mudah untuk menghasilkan pengujian unit yang gagal yang mewajibkan perilaku tertentu ketika kita sudah memiliki definisi kelas dan metode.

Pada contoh di bawah ini (ditulis dalam C# menggunakan XUnit), sebuah instance SalesTaxSelector memunculkan pengecualian yang sesuai ketika pengujian memanggil metode Select() pada pengidentifikasi negara yang belum mendapatkan SalesTax yang sesuai:

Bagus. Namun, satu-satunya alasan kami dapat menjalankan pengujian unit ini adalah karena

  1. Kami memiliki kelas SalesTaxSelector, termasuk konstruktor default, dan
  2. SalesTaxSelector memiliki metode Select() publik.

Itu bagus, tapi bagaimana kita mendapatkannya?

Tes Perancah

Mari kita mulai dari atas; persyaratan paling dasar — ​​bagaimana kita mendapatkan kelas SalesTaxSelector? Tes unit apa yang bisa kita tulis — dan inilah inti — untuk mendorong kita ke definisiSalesTaxSelector?

Akankah tes ini berhasil?

Sebentar; itu tidak akan berhasil. Tes unit tidak dapat dikompilasi; kami tidak memiliki definisi untuk SalesTaxSelector!

Apakah kegagalan kompilasi ini tidak mendorong kita untuk membuat kelas SalesTaxSelector?

Tentu saja demikian.

Oleh karena itu, setelah kita menulis definisi kelas sederhana, pengujian unit yang gagal akan lolos:

Anda akan menyadari bahwa kami hanya menghasilkan implementasi, definisi kelas kosong untuk SalesTaxSelector, sebagaimana ditentukan oleh Aturan 3 dari Tiga Aturan TDD.

Jadi, untuk mengikuti aturan TDD, kami memerlukan pengujian unit yang mendorong kami menerapkan definisi SalesTaxSelector-sebuah Tes Scaffolding.

Industri konstruksi menggunakan perancah yang telah disiapkan untuk membentuk beton tuang hingga kering. Setelah beton mengeras, pekerja melepas perancah, dan struktur beton akan berdiri kokoh.

Demikian pula, kami hanya memerlukan pengujian scaffolding untuk membangun infrastruktur pemrograman yang diperlukan - kelas atau metode - setelah itu, pengujian tersebut tidak lagi berguna bagi kami.

Oke, kami telah menemukan pengujian scaffolding untuk file . Mari kita gunakan pendekatan pengujian unit scaffolding untuk menghasilkan SalesTaxSelector's Select() :

Sekali lagi, pengujian unit menghadapkan kami pada kesalahan kompilasi untuk metode Select() yang tidak diketahui, yang segera diperbaiki dengan menerapkan versi dasar pada SalesTaxSelector kami:

Sekali lagi, perhatikan bagaimana kami merepresentasikan metode Select() dalam istilah yang paling sederhana:

Spesifik penerapan metode Select() yang diperlukan akan dihasilkan dari pengujian unit lebih lanjut. Tes scaffolding ada untuk menghasilkan definisi kelas dan metode publik.

Selanjutnya, perhatikan bagaimana tidak ada pernyataan dalam Tes Scaffolding. Kita tidak menguji perilaku konkret, seperti yang biasa kita lakukan dengan pengujian unit, namun di sini kita hanya ingin menghasilkan kelas dan metode dengan mengatasi kesalahan kompilasi dengan implementasi kelas dan metode.

Apakah Ini Diperlukan?

Sepintas lalu, mendefinisikan Tes Scaffolding dan kemudian membuatnya lulus dengan definisi kelas dan metode yang sepele tampak seperti pekerjaan yang berhasil. Mengapa repot-repot melakukan tes scaffolding ketika kita memahami kelas atau metode yang ingin kita definisikan?

Saya selalu mendengar keberatan mengenai tes scaffolding. Inilah alasan saya menyimpannya:

Menghindari Lereng yang Licin

Beralih dari penerapan TDD yang ketat, di mana kita dengan setia mengikuti Tiga Aturan dan oleh karena itu menulis semua kode implementasi hanya ketika kita memiliki tes yang melanggar, penuh dengan masalah. Berdasarkan pengalaman saya, praktisi TDD baru yang mengabaikan pengujian scaffolding cenderung dengan cepat kembali menulis terlalu banyak kode tanpa pengujian unit hingga mereka tidak lagi mempraktikkan TDD. Menerapkan Tiga Aturan secara konsisten dan memercayai proses TDD, dibandingkan mencari jalan pintas, kemungkinan besar akan membawa kesuksesan TDD.

Kesimpulan

Pengujian unit yang mendorong kita untuk membuat kelas yang sedang diuji dan metode publiknya disebut Tes Perancah. Jenis pengujian TDD khusus ini membantu kita tetap setia pada aturan bahwa kita tidak boleh menulis kode kecuali pengujian kita gagal. Tes scaffolding tidak mengkodekan perilaku program yang diharapkan; oleh karena itu, kami dapat menghapusnya setelah mereka menyelesaikan tugasnya.

Jika Anda menikmati artikel ini, silakan tinggalkan beberapa tepuk tangan — dan banyak tepuk tangan jika Anda menyukainya! :) Terima kasih.

Bergabunglah dengan daftar email saya untuk mempercepat karir rekayasa perangkat lunak Anda.

Saat mendaftar, Anda akan mendapatkan panduan saya, 'Jalan Menuju Master Progammer', yang berisi 3 ide hebat untuk membantu Anda mempersingkat perjalanan Anda menjadi programmer ahli.