Apakah BDD scalable untuk proyek menengah ke besar?


22

Di setiap situs web yang Anda baca tentang BDD (Behaviour Driven Development), Anda menemukan contoh yang sangat sederhana yang menunjukkan kepada Anda betapa jelas dan mudahnya mendefinisikan persyaratan Anda. Tetapi mencoba menerapkan proses ini dalam produk besar (bukan contoh kalkulator) menunjukkan kepada saya bahwa segala sesuatu dapat (atau akan didapat) cukup rumit dan tidak dapat dibaca; terutama mengubah permintaan pada titik selanjutnya berarti banyak pekerjaan untuk memperbaiki tes Integrasi untuk ini.

Jadi saya bertanya-tanya, apakah BDD benar-benar layak? Apakah itu memecahkan masalah yang tidak dimiliki teknik lain!


Sayang sekali, saya pikir masalah ini cukup konstruktif mengingat BDD menjadi lebih populer akhir-akhir ini.
DD

1
Jika ada orang yang memiliki cukup perwakilan dapat menyarankan membuka kembali itu akan menjadi orang hebat.
DD

Saya akan membuka kembali, tetapi Anda sudah menerima jawaban pertama ...
MattDavey

1
Saya menerima karena sudah ditutup, jadi saya tahu tidak ada lagi jawaban yang mungkin, tetapi saya benar-benar terlibat dalam lebih banyak laporan pengalaman tentang hal ini, saya akan menerimanya untuk saat ini
DD

2
ok hebat :) Saya pikir Anda harus mengedit sedikit pertanyaan. Saya pikir pertanyaan Anda adalah tentang skalabilitas BDD dalam proyek-proyek besar. "Apakah BDD benar-benar baik" adalah subyektif, "Apakah skala BDD baik untuk proyek-proyek besar" sedikit lebih objektif.
MattDavey

Jawaban:


6

Saya pikir salah satu sumber terbaik pada BDD adalah Spesifikasi oleh Contoh buku . Ini menceritakan banyak tentang bagaimana mengatur tes BDD dan bagaimana mereka harus ditulis sehingga tidak menyebabkan banyak pengerjaan ulang ketika persyaratan berubah.

Jika segala sesuatunya menjadi rumit atau rumit dalam tes Anda, maka mungkin Anda melakukan sesuatu yang salah. Sama dengan BDD dan TDD. Menulis tes yang bagus itu sulit dan butuh berbulan-bulan untuk mempelajarinya.


3
TDD tidak sama, pengujian unit yang telah ditentukan tidak akan pernah dapat menjadi kompleks kecuali jika Anda memiliki unit terlalu besar yang merupakan bau kode, tetapi tes Integrasi seharusnya menguji interaksi antara lebih dari satu unit, fungsionalitas total, ini memungkinkan kompleksitasnya meningkat linier ke syarat-syarat, masih Anda tidak dapat memecahkannya dalam potongan-potongan kecil karena itu tidak akan menjadi tes inegtrasi lagi jika dilakukan.
DD

Anda dapat melampirkan beberapa tes BDD yang rumit dan saya bisa melihat apa yang bisa dilakukan untuk membuatnya lebih sederhana.
Piotr Perak

Itu tidak mudah, yang saya miliki di sini bukan dalam bahasa Inggris saya harus menerjemahkannya, jika saya tidak menemukan persyaratan yang saya dapat dengan mudah menerjemahkan ke bahasa Inggris saya dapat melampirkannya, tetapi masih kode di belakang adalah masalah juga yang akan menjadi terlalu besar untuk dilampirkan di sini dalam satu pos.
DD

Mengapa ini diturunkan? Saya memberikan sumber yang bagus yang akan membantu OP memecahkan masalahnya.
Piotr Perak

itu bukan saya, saya akan memberikan +1 sebagai kompensasi tetapi saya bisa melakukan ini hanya dalam 14 jam karena saya menggunakan semua 30 suara saya untuk hari ini.
DD

5

Mungkin membantu untuk menyadari bahwa fokus BDD adalah percakapan . BDD benar-benar alat analisis yang terjadi untuk memberikan beberapa pengujian regresi sebagai produk sampingan yang bagus.

Saya telah menggunakan skenario di semua jenis level dalam percakapan; dari mengidentifikasi pemangku kepentingan yang berbeda untuk melihat apakah rilis kemungkinan akan diterima dengan baik, untuk mengetahui bagaimana sebuah modul atau kelas harus berperilaku .

Ada beberapa petunjuk dan tips yang bisa saya sarankan untuk membuat ini lebih mudah.

Jika Anda belum pernah melakukannya sebelumnya, itu akan berubah.

Apa pun yang baru pada domain, atau bisnis, kemungkinan akan berubah. Anda mungkin menyadari bahwa Anda berada dalam ruang ini jika Anda berbicara melalui skenario, menanyai mereka , dan bisnis berkata, "Oh, saya tidak yakin." Itu pertanda baik untuk berhenti mencoba melakukan BDD dan melakukan sesuatu untuk mendapatkan umpan balik yang lebih cepat, untuk membantu bisnis mengetahui apa yang mereka inginkan. Setelah ide-ide stabil, skenario dapat ditulis dalam retrospeksi.

Semua proyek memiliki beberapa aspek bagi mereka yang baru, atau Anda tidak akan melakukannya.

Jika Anda pernah melakukannya sebelumnya, itu membosankan.

Seperti halnya aspek baru yang membedakan , proyek biasanya memiliki beberapa aspek komoditisasi yang serupa dengan yang sudah dilakukan. Misalnya, jika saya memproduksi ponsel baru, masih perlu melakukan panggilan. "Lakukan panggilan telepon" adalah skenario yang sangat terkenal sehingga kita tidak perlu membicarakannya. Demikian pula, hal-hal seperti "masuk" atau bahkan "pendaftaran pengguna" membosankan.

Jika memungkinkan, gunakan pustaka untuk ini, dan kemudian Anda tidak perlu menulis skenario di sekitar mereka. Juga, melakukan bit lainnya pertama - telah yang sudah-login pengguna dan bekerja keluar apa yang dia ini logging di untuk . Area-area ini tidak mungkin berubah, jadi Anda mungkin bisa lolos dengan pengujian manual.

Jika seseorang pernah melakukannya sebelumnya, berbicara melalui skenario dapat membantu.

Ada sedikit di antara di mana kita memiliki persyaratan khusus domain, hal-hal yang relatif dipahami dengan baik oleh seseorang , dan di mana ketidakpastian sebenarnya sebagian besar berada di sekitar ruang lingkup daripada perilaku aktual sistem.

Berbicara melalui skenario dapat membantu tim pengembang untuk menemukan perilaku, untuk memanfaatkan pengetahuan seorang ahli, dan untuk memastikan bahwa perilaku yang diketahui dan berharga dapat ditangkap.

Ini adalah bagian di mana BDD bekerja paling baik. Kiat saya adalah menulis skenario paling menarik di bagian atas file fitur (atau wiki, jika Anda tidak mengotomatiskan) dan menghapus semua skenario yang digandakan atau mudah disimpulkan sebagai hasilnya.

Jika memungkinkan, gunakan skenario hanya sebagai contoh cara kerja aplikasi . Misalnya, jika Anda ingin menunjukkan cara kerja validasi, perlihatkan beberapa contoh bagaimana aplikasi membantu pengguna mengisi formulir. Periksa validasi dengan ketat menggunakan pengujian unit, yang jauh lebih mudah untuk dipertahankan dan lebih cepat dijalankan.

Bacaan lebih lanjut

Jika Anda tertarik dengan ini, berikut adalah beberapa hal yang saya tulis yang mungkin bisa membantu.

BDD di besar

Cynefin untuk devs , yang masuk ke dalam tiga area ini lebih terinci

Slide tutorial saya , yang semuanya bagus dan beranotasi untuk Anda, dan mencakup seluruh tumpukan juga.


Terima kasih atas jawaban yang informatif ini, baca tautan yang Anda lampirkan
DD

3

Kami membangun sebuah proyek (kompleksitas domain ) yang cukup rumit musim gugur lalu dan saya dapat dengan jujur ​​mengatakan meletakkan pekerjaan muka ke dalam BDD menyelamatkan proyek. Saya telah melihat korelasi kuat antara kompleksitas domain dan manfaat BDD.

Biarkan saya menyingkirkan satu hal: menguji aturan bisnis yang rumit itu sulit. Pertanyaannya adalah, apakah Anda ingin mencoba dan mengingat semua skenario gila setiap kali Anda melakukan perubahan, atau apakah Anda ingin jaring pengaman itu memberi tahu Anda ketika Anda telah melanggar spesifikasi. Habiskan waktu di muka dan kerjakan semua skenario, tuliskan, dan akhirnya tulis semua tes untuk mereka.

Dan ketika Anda kembali lagi nanti untuk mencoba memahami sesuatu, memiliki spesifikasi yang dapat diuji itu adalah penyelamat hidup.


1

BDD adalah proses pengembangan berdasarkan TDD (Test Driven Development) Berikut adalah beberapa pro dan kontra dari TDD yang diambil dari pengalaman pribadi saya:

  • TDD, pastikan lingkup Anda didefinisikan dengan baik. Dengan cara ini, Anda merancang kasus uji Anda terlebih dahulu. Dengan demikian menetapkan harapan untuk potongan kode yang seharusnya Anda tulis.
  • TDD adalah cara menjaga kode Anda. Asumsikan Anda menulis fungsi sederhana dan kemudian Anda menambahkan beberapa kondisi switching kompleks dalam fungsi yang sama ini. Besok, jika orang lain ingin memodifikasi fungsi ini, ia dapat merujuk ke test case. Jika dia ingin mengubah fungsi Anda, maka, ia juga harus mengubah test case (sebagian besar waktu). Ini memungkinkan dia untuk memahami bahwa ada alasan di balik apa yang Anda tulis.
  • TDD memungkinkan pengembangan perangkat lunak yang lebih cepat. Masing-masing dari kita akan menghadapi masalah ini saat coding. Kami memulai dengan sebuah ide. Dan perlahan-lahan kehilangan jejak itu. Kami akhirnya meletakkan potongan kode yang tidak diinginkan untuk menangani beberapa skenario. Di TDD, Anda menetapkan harapan di muka. Dengan demikian, Anda membatasi diri untuk tidak terlalu jauh dari tujuan.
  • TDD memungkinkan Anda untuk menangkap kemungkinan bug sebelum proyek online. Ini terutama berkaitan dengan kualitas kasus uji yang ditulis.

Cons:

  • Pada awalnya, TDD bisa sedikit rumit. Banyak orang tidak memahami konsep pengembangan uji kasus mengemudi.
  • TDD, terkadang dapat menyebabkan upaya besar dalam pemeliharaan. Ini ada hubungannya dengan kasus uji yang tidak diinginkan, atau tidak berarti.
  • TDD harus diambil dengan sejumput garam. Tidak ada pengembang suka menghabiskan waktu pada beberapa test case yang ditulis oleh orang lain. Menguraikan arti dari testcase kadang-kadang dapat menyebabkan sakit kepala besar.

Saya mengerjakan proyek dengan lebih dari 900.000 baris kode. Dan saya masih mengikuti BDD. Satu hal utama yang perlu Anda pertimbangkan adalah jumlah kesalahan yang mungkin Anda tangkap murni karena kasus uji. Beberapa tahun kemudian, Anda akan disumpah oleh BDD!


2
Anda harus menjelaskan lebih lanjut tentang perbedaan antara BDD dan TDD dan di mana bagian DDD masuk.
Benjamin Gruenbaum

1
@BenjaminGruenbaum Idealnya, tidak ada perbedaan antara BDD dan TDD. BDD bila diikuti dengan benar sama dengan TDD! Jadi saya tidak melihat alasan untuk membawa perbedaan sebagai bagian dari jawaban. Terima kasih untuk sarannya!
Ricketyship

1
"TDD memungkinkan pengembangan perangkat lunak yang lebih cepat." Adakah penelitian yang mengkonfirmasi hal ini? Hanya penasaran. Saya juga akan menyebutkan bahwa mempercepat tidak linier.
Den

2
@AlexandreMartins Hah, tentu saja! Jauh lebih penting untuk mengetahui bahwa Anda mungkin memiliki tes & skenario kualitas buruk daripada berpura-pura mereka semua IMO baik.
Lunivore

2
@Lunivore Ya itulah yang mengganggu saya dalam kasus BDD / TDD. Kasus uji harus kuat. Sayangnya ada pandangan ini dalam komunitas pengembangan bahwa selama ada kasus uji, tidak apa-apa! Saya pernah melihat test case di mana ada baris yang dimasukkan ke dalam tabel menggunakan pernyataan sql dan hal yang sama dinyatakan pada langkah selanjutnya! Apakah pengembang mencoba menguji fungsionalitas oracle ?!
Ricketyship
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.