Bos Anda Tidak Akan Menghargai TDD: Coba Contoh Pengembangan Berbasis Perilaku Ini

Pengujian. Ini sering dibiarkan hingga menit terakhir, lalu dipotong karena Anda kehabisan waktu, anggaran berlebih, atau apa pun.

Manajemen bertanya-tanya mengapa pengembang tidak bisa hanya "melakukannya dengan benar pertama kali", dan pengembang (terutama pada sistem besar) dapat lengah ketika pemangku kepentingan yang berbeda menggambarkan bagian yang berbeda dari sistem, seperti kisah orang buta yang menggambarkan gajah.

Namun, tidak dapat dihindari bahwa langkah pertama dalam setiap proyek adalah diskusi tentang perilaku perangkat lunak atau fitur yang akan dibangun. Seorang klien atau pebisnis mendatangi seseorang di tim pengembangan dan menjelaskan apa yang mereka inginkan.

Terkadang interaksi ini datang dalam bentuk cerita pengguna Agile. Terkadang mereka datang dalam bentuk dokumen desain, seperti dalam entri blog Chris Fox tahun lalu. Mereka juga bisa datang sebagai diagram alur atau maket di Keynote, atau bahkan panggilan telepon yang terburu-buru.

Dari komunikasi ini saja, pengembang bertanggung jawab untuk membangun sistem yang “berfungsi”. Ini sangat sulit bagi pekerja lepas yang bekerja di luar sistem yang lebih besar.

Mengapa pengujian dipotong?

Ada celah yang jelas di sini: jika pemilik bisnis telah membayangkan perilaku sistem di awal, mengapa menguji bahwa perilaku ini benar-benar berfungsi sering kali merupakan langkah yang dipotong?

Jawabannya mungkin sangat sederhana: ujian sering kali tidak dilihat sebagai modal bersama ; mereka tidak dianggap memiliki nilai untuk proyek, karena "mereka hanya untuk para insinyur", atau dengan cara yang sama, memberikan nilai kepada satu departemen atau sekelompok orang.

Bagaimana kita menguji modal bersama ini, daftar perilaku sistem ini? Dengan merangkul tidak hanya pengembangan yang digerakkan oleh tes (TDD), tetapi pengembangan yang digerakkan oleh perilaku (BDD).

Apa itu BDD?

Pengembangan berbasis perilaku harus difokuskan pada perilaku bisnis yang diterapkan kode Anda: "mengapa" di balik kode . Ini mendukung alur kerja yang berpusat pada tim (terutama lintas fungsi).

Saya telah melihat BDD tangkas bekerja dengan sangat baik ketika pengembang dan pemilik produk Agile atau analis bisnis duduk bersama dan menulis spesifikasi yang tertunda (untuk diisi nanti oleh pengembang) dalam editor teks biasa:

1. Pelaku bisnis menentukan perilaku yang ingin mereka lihat dalam sistem.
2. Pengembang mengajukan pertanyaan berdasarkan pemahaman mereka tentang sistem, sementara juga menuliskan perilaku tambahan yang diperlukan dari perspektif pengembangan.

Idealnya, kedua belah pihak dapat merujuk ke daftar perilaku sistem saat ini untuk melihat apakah fitur baru ini akan merusak fitur yang ada.

Saya telah menemukan tindakan sederhana ini memberi saya batasan yang cukup sehingga saya dapat berpikir seperti seorang pengembang: "mengingat saya harus mengimplementasikan tes ini, bagaimana hal itu membatasi saya/semua orang ke dalam spesifikasi yang dapat saya terapkan dalam kode"? Karena mereka menunggu spesifikasi, mereka cepat dan mudah ditulis di tengah-tengah kolaborasi.

Pendekatan kolaboratif ini memungkinkan saya fokus pada apa yang disediakan fitur untuk pengguna akhir, dan memiliki orang bisnis di sana membatasi saya untuk berbicara tentang perilaku, bukan implementasi. Ini menyoroti perbedaan dalam BDD vs TDD.

Mari kita lihat contoh Pengembangan Berbasis Perilaku

Skenario: Anda adalah pengembang di tim yang bertanggung jawab atas sistem akuntansi perusahaan, yang diimplementasikan di Rails. Suatu hari, seorang pebisnis meminta Anda untuk menerapkan sistem pengingat untuk mengingatkan klien tentang tagihan mereka yang tertunda. Karena Anda berlatih BDD per tutorial ini; (versus TDD), Anda duduk dengan pebisnis itu dan mulai mendefinisikan perilaku.

Anda membuka editor teks dan mulai membuat spesifikasi tertunda untuk perilaku yang diinginkan pengguna bisnis:

 it "adds a reminder date when an invoice is created" it "sends an email to the invoice's account's primary contact after the reminder date has passed" it "marks that the user has read the email in the invoice"

Fokus pada perilaku selama pengembangan ini menjadikan pengujian berguna sebagai verifikasi bahwa Anda sedang membangun fitur yang tepat, bukan hanya bahwa kode Anda benar. Perhatikan bahwa ungkapan dalam bahasa bisnis, bukan dalam bahasa implementasi internal sistem. Anda tidak melihat atau peduli bahwa faktur adalah belongs_to akun, karena tidak ada orang di luar tim pengembangan yang peduli tentang itu.

Beberapa pengembang lebih suka menulis kasus uji di tempat, memanggil metode dalam sistem, menyiapkan harapan, seperti:

 it "adds a reminder date when an invoice is created" do current_invoice = create :invoice current_invoice.reminder_date.should == 20.days.from_now end

Rangkaian pengujian akan gagal karena kita belum menulis kode untuk menyetel reminder_date .

Berhadapan dengan spesifikasi yang gagal

Saya memahami pengembang yang menulis spesifikasi yang gagal, tetapi dengan pebisnis di sisi saya, ini tidak pernah berhasil untuk saya. Orang bisnis yang salah akan terganggu oleh detail atau mengambil pengetahuan baru ini dan mencoba mengelola mikro hal-hal yang lebih diketahui pengembang (desain basis data yang tepat, penggunaan kembali kode).

Dalam pengalaman saya, menulis lebih dari satu baris ikhtisar tentang perilaku tertentu akan membuat pebisnis bosan. Mereka akan melihatnya sebagai penggunaan waktu yang buruk atau menjadi cemas untuk menggambarkan perilaku berikutnya saat itu ada di pikiran mereka.

Bagaimana BDD berbeda dari TDD?

Mari kita lihat ini dengan cara yang berbeda, dengan pendekatan Pengembangan Berbasis Tes, dan tuliskan tes yang tertunda:

 it "after_create an Invoice sets a reminder date to be creation + 20 business days" it "Account#primary_payment_contact returns the current payment contact or the client project manager" it "InvoiceChecker#mailer finds invoices that are overdue and sends the email"

Tes ini bermanfaat, tetapi hanya membantu satu kelompok orang: insinyur. BDD berguna untuk berkomunikasi dengan setiap anggota tim produk lintas fungsi.

Anda tentu saja dapat melakukan pengembangan uji-pertama saat dalam pola pikir BDD melalui penggunaan perilaku yang tertunda. Pertama, tulis tesnya; lalu jalankan (merah); kemudian membuatnya bekerja (hijau); lalu perbaiki (refactor).

Banyak pekerjaan di komunitas BDD telah dilakukan untuk membuat pemeriksaan pernyataan di dalam tes dibaca seperti bahasa Inggris. Berikut tes RSpec stereotip:

 a = 42 a.should == 42

Format ini membuat segalanya lebih mudah dibaca nanti. Tapi ingat ini bukan yang kita lakukan di sini—intinya adalah menurunkan perilaku secepat mungkin —dan menegakkan prinsip 'satu perilaku yang diuji per spesifikasi'. Idealnya, judul spesifikasi yang tertunda akan memberi tahu Anda apa yang Anda uji.

BDD bukan tentang cara mewah untuk memvalidasi hasil Anda; ini tentang berbagi perilaku yang diharapkan di semua anggota tim.

Pengembangan yang didorong oleh perilaku adalah tentang kolaborasi & komunikasi

Mari kita kembali ke skenario kita: mengerjakan sistem akuntansi perusahaan.

Anda berjalan melalui fungsionalitas item dengan orang bisnis, dengan Anda menganalisis sistem melalui internalnya (bagaimana objek cocok bersama secara internal), dan mereka menganalisis sistem dari luar.

Anda memikirkan beberapa kondisi dan bertanya kepada analis bisnis apa yang terjadi dalam skenario berikut:

 * What's the default reminder date going to be? How many days before the invoice due date? * Are those business days or just calendar days? * What happens if there's not a primary contact associated with the account?

Dan Anda mendapatkan jawaban . Sangatlah penting bagi pebisnis untuk memahami bahwa Anda tidak mencoba membuat lubang dalam ide peliharaan mereka, atau menjadi terlalu bertele-tele.

Dengan cara ini, Behavior-Driven Development adalah alat untuk membantu kolaborasi dan memulai percakapan antara kedua departemen. Ini juga merupakan cara untuk memperjelas cakupan fitur yang diinginkan dan mendapatkan perkiraan yang lebih baik dari tim pengembang. Mungkin Anda menyadari bahwa tidak ada cara untuk menghitung 10 hari kerja dari titik waktu tertentu; itu fitur tambahan, terpisah, yang harus Anda terapkan.

Pengembang akan memiliki pertimbangan pengembang ("Apa sebenarnya maksud Anda ketika Anda mengatakan, 'hari'?"), Sementara pebisnis akan memiliki pertimbangan mereka sendiri ("Tolong jangan gunakan istilah terlambat di sini, artinya berbeda"). Memiliki satu grup atau yang lain pergi dan mencoba menulis tes perilaku logika bisnis ini sendiri (janji Mentimun) memotong input berharga masing-masing pihak.

Ini juga merupakan pengganti yang baik ketika Klien Agile tidak lagi secara fisik berada di ruangan: untuk memiliki keinginan mereka di atas kertas, dicampur dengan analisis pengembang (dan terjemahan) dari apa yang Anda bangun.

Dokumen desain

Posting Blog Toptal sebelumnya Chris Fox berbicara tentang dokumen desain, terutama di awal proyek. Memahami dan mengekstraksi skala perilaku bisnis dari proyek-proyek di mana sistemnya agak dapat diketahui, ke proyek-proyek yang membutuhkan puluhan tahun programmer untuk mencapainya dan memiliki ratusan atau ribuan spesifikasi perilaku.

Artikel Chris juga menyebutkan perilaku elemen di layar, dan ini adalah area di mana saya selalu berselisih dengan desainer: "Seperti apa tampilan tombol ini saat redup" atau, "Bagaimana tampilannya di layar 11", karena halaman ini jelas dirancang untuk layar 24”? Bolak-balik dengan pelaku bisnis ini dapat menemukan celah dalam aset grafis proyek atau tata letak halaman.

Dalam tim lintas fungsi yang sangat besar, ada banyak anggota tim dengan masalah mereka sendiri: desainer, pengembang, kemungkinan seseorang dari operasi, administrator database—mungkin orang QA (ya, ada tempat untuk semua orang di TDD dan BDD!), masing-masing dengan keprihatinan dan pertanyaan mereka sendiri. BDD dapat mendorong kolaborasi ini lebih dari yang dilakukan oleh pengembangan yang didorong oleh pengujian. Dari "apa yang terjadi ketika data terlalu besar untuk tabel ini?" untuk, "Hmmm, itu akan menjadi permintaan yang mahal, kami ingin menyimpannya dalam cache" hingga, "Tunggu, haruskah pengguna melihat semua informasi rahasia itu?", Mungkin ada lebih banyak yang dipertaruhkan daripada hanya pengembang dan seorang analis bisnis dengan pertanyaan tentang fitur baru ini

Pengembangan yang didorong oleh perilaku adalah tentang artefak bersama

Apa yang dimaksud dengan artefak bersama?

Saya suka memikirkan "artefak" dalam rekayasa perangkat lunak sebagai hal yang berpotensi fisik yang menggambarkan proyek atau tim proyek, dan yang dapat ditemukan enam bulan ke depan. Artefak yang baik menjelaskan mengapa segala sesuatunya seperti itu.

Percakapan di lorong bukanlah artefak. Juga bukan gambar papan tulis. Gambar papan tulis yang diubah menjadi dokumentasi kelas panjang atau dokumen desain— ini adalah artefak. Notulen rapat juga merupakan artefak.

Artefak adalah beberapa kode sumber yang disimpan ke repositori atau ruang bersama, dan tiket di sistem tiket, atau catatan di Wiki internal—atau bahkan log obrolan tetap.

Artefak bersama, menurut saya, adalah artefak terbaik . Mereka tidak hanya menunjukkan mengapa sesuatu seperti itu, tetapi mengapa itu ada di aplikasi sama sekali .

Bagaimana Anda menggunakannya di BDD?

Perilaku harus menjadi artefak tim bersama—tes seharusnya tidak hanya menjadi pekerjaan sibuk bagi programmer! Meskipun yang terbaik adalah memiliki sistem di mana seluruh tim dapat dengan mudah melihat spesifikasi saat ini (mungkin sistem penerapan juga mengekstrak dan menyimpan daftar perilaku ke area pribadi situs atau wiki), Anda juga dapat melakukannya secara manual setiap lari cepat.

Nama permainannya adalah "membantu pengembang membuat spesifikasi yang kami butuhkan untuk memberikan nilai bisnis lebih cepat, berkolaborasi antardepartemen, dan membuat perkiraan yang lebih baik".

Pemahaman seluruh perusahaan tentang apa yang dilakukan sistem ini juga merupakan bentuk modal. Ini adalah "mengapa" untuk kode "bagaimana".

Kesimpulan

Bagaimana kami memecahkan masalah perangkat lunak buggy yang dikirimkan ke pelanggan? Dengan memastikan bahwa pengujian tidak dilihat sebagai sesuatu yang “hanya dipedulikan oleh pengembang”.

Menggambarkan dan memahami kebutuhan sistem memiliki banyak manfaat di luar kebenaran kode: membangun dialog antar-departemen dan memastikan semua perhatian pemangku kepentingan terpenuhi (dan bukan hanya pemangku kepentingan dengan gelar besar yang mewah). Menggunakan pengembangan yang didorong oleh perilaku untuk memahami kebutuhan ini dari awal dan menguji perilaku bisnis eksternal yang diperhatikan oleh seluruh tim— itu adalah cara yang bagus untuk memastikan proyek yang berkualitas.