Test-Driven Development adalah metodologi pengembangan perangkat lunak yang pertama kali diuji, yang artinya diperlukan penulisan kode uji sebelum menulis kode aktual yang akan diuji. Dalam kata-kata Kent Beck:
Gaya di sini adalah menulis beberapa baris kode, kemudian tes yang harus dijalankan, atau bahkan lebih baik, untuk menulis tes yang tidak akan berjalan, kemudian menulis kode yang akan membuatnya berjalan.
Setelah mencari tahu cara menulis sepotong kecil kode, sekarang, alih-alih hanya menulis, kami ingin segera mendapatkan umpan balik dan mempraktikkan "sedikit kode, uji sedikit, kode sedikit, tes sedikit." Jadi kami segera menulis tes untuk itu.
Jadi TDD adalah metodologi teknis tingkat rendah yang digunakan pemrogram untuk menghasilkan kode bersih yang berfungsi.
Pengembangan Berbasis Perilaku adalah metodologi yang dibuat berdasarkan TDD, tetapi berkembang menjadi proses yang tidak hanya menyangkut pemrogram dan penguji, melainkan berurusan dengan seluruh tim dan semua pemangku kepentingan penting, teknis dan non-teknis. BDD memulai dari beberapa pertanyaan sederhana yang TDD tidak jawab dengan baik: berapa banyak tes yang harus saya tulis? Apa yang sebenarnya harus saya uji — dan apa yang seharusnya tidak saya uji? Manakah dari tes yang saya tulis akan menjadi penting bagi bisnis atau untuk kualitas produk secara keseluruhan, dan yang mana yang merupakan rekayasa berlebihan saya?
Seperti yang Anda lihat, pertanyaan seperti itu membutuhkan kolaborasi antara teknologi dan bisnis. Stakeholder bisnis dan pakar domain seringkali dapat memberi tahu para insinyur tes seperti apa yang tampaknya bermanfaat — tetapi hanya jika tes tersebut merupakan tes tingkat tinggi yang berhubungan dengan aspek bisnis penting. BDD menyebut tes seperti bisnis sebagai "contoh," seperti pada "katakan padaku contoh bagaimana fitur ini harus berperilaku dengan benar," dan cadangan kata "tes" untuk tingkat rendah, pemeriksaan teknis seperti validasi data atau pengujian integrasi API. Bagian yang penting adalah bahwa sementara tes hanya dapat dibuat oleh programmer dan penguji, contoh - contoh dapat dikumpulkan dan dianalisis oleh seluruh tim pengiriman — oleh desainer, analis, dan sebagainya.
Dalam sebuah kalimat, salah satu definisi terbaik dari BDD yang saya temukan sejauh ini adalah bahwa BDD adalah tentang "melakukan percakapan dengan para ahli domain dan menggunakan contoh-contoh untuk mendapatkan pemahaman bersama tentang perilaku yang diinginkan dan menemukan yang tidak diketahui." Bagian penemuan sangat penting. Ketika tim pengiriman mengumpulkan lebih banyak contoh, mereka mulai semakin memahami domain bisnis dan dengan demikian mereka mengurangi ketidakpastian mereka tentang beberapa aspek produk yang harus mereka tangani. Ketika ketidakpastian berkurang, kreativitas dan otonomi tim pengiriman meningkat. Misalnya, mereka sekarang dapat mulai menyarankan contoh mereka sendiri bahwa pengguna bisnis tidak berpikir itu mungkin karena kurangnya keahlian teknologi.
Sekarang, berbincang dengan pakar bisnis dan domain terdengar hebat, tetapi kita semua tahu bagaimana itu sering berakhir dalam praktik. Saya memulai perjalanan saya dengan teknologi sebagai programmer. Sebagai pemrogram, kita diajarkan untuk menulis kode — algoritma, pola desain, abstraksi. Atau, jika Anda seorang desainer, Anda diajarkan mendesain—Organisasikan informasi dan buat antarmuka yang indah. Tetapi ketika kita mendapatkan pekerjaan entry-level kita, majikan kita mengharapkan kita untuk "memberikan nilai kepada klien." Dan di antara klien-klien itu bisa, misalnya ... bank. Tetapi saya tidak tahu apa-apa tentang perbankan — kecuali cara mengurangi saldo akun saya secara efisien. Jadi saya harus entah bagaimana menerjemahkan apa yang diharapkan dari saya ke dalam kode ... Saya harus membangun jembatan antara perbankan dan keahlian teknis saya jika saya ingin memberikan nilai apa pun. BDD membantu saya membangun jembatan yang kokoh di atas fondasi komunikasi yang lancar antara tim pengiriman dan pakar domain.
Belajarlah lagi
Jika Anda ingin membaca lebih lanjut tentang BDD, saya menulis buku tentang hal itu. "Menulis Spesifikasi Hebat" mengeksplorasi seni menganalisis persyaratan dan akan membantu Anda belajar bagaimana membangun proses BDD yang hebat dan menggunakan contoh sebagai bagian inti dari proses itu. Buku ini berbicara tentang bahasa di mana-mana, mengumpulkan contoh, dan membuat apa yang disebut spesifikasi yang dapat dieksekusi (tes otomatis) dari contoh-contoh — teknik yang membantu tim BDD memberikan softeware hebat tepat waktu dan sesuai anggaran.
Jika Anda tertarik untuk membeli "Spesifikasi Bagus Menulis," Anda dapat menghemat 39% dengan kode promo 39nicieja2 :)