Hubungan antara BDD dan TDD


30

Apa hubungan BDD dan TDD?

Dari apa yang saya mengerti, BDD menambahkan dua hal utama pada TDD: tes penamaan (pastikan / harus) dan tes penerimaan. Haruskah saya mengikuti TDD selama pengembangan oleh BDD? Jika ya, haruskah pengujian unit TDD saya dinamai dengan gaya sure / should yang sama?


1
BDD adalah satu set TDD yang terdokumentasi dengan baik (Unitests)
DD

Adakah yang ingin menambahkan jawaban dari kemah Bevenor Driven Design ? Dari sudut pandang saya, semua jawaban ini adalah tentang beberapa iterasi pertama BDD. Aplikasi BDD yang sukses akhir-akhir ini seringkali lebih dekat dengan desain , dan bahkan dapat menghilangkan pengujian otomatis sepenuhnya, jika perlu.
Paul Hicks

Perbedaan antara BDD dan TDD seperti perbedaan antara Ekonomi Makro dengan Ekonomi Mikro. BDD = membangun pemahaman tentang persyaratan menggunakan contoh dan secara opsional dapat digunakan untuk menggerakkan tes Makro otomatis. (agilenoir.biz/en/am-i-behavioral-or-not), TDD = menulis tes mikro untuk mendorong penulisan kode. Podcast Agile Thoughts mencakup perbedaan-perbedaan ini juga: agilenoir.biz/en/agilethoughts/test-automation-pyramid-series
Lance Kind

Jawaban:


37

BDD menambahkan siklus di sekitar siklus TDD.

Jadi, Anda mulai dengan perilaku dan membiarkan hal itu mendorong tes Anda, kemudian membiarkan tes mendorong pengembangan. Idealnya, BDD didorong oleh semacam tes penerimaan, tetapi itu tidak 100% diperlukan. Selama Anda memiliki perilaku yang diharapkan, Anda baik-baik saja.

Jadi, katakanlah Anda sedang menulis Halaman Masuk.

Mulai dengan jalan bahagia:

Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page

Sintaks yang diberikan-dan-kapan-kemudian-kemudian-dan umum dalam pengembangan perilaku-didorong. Salah satu keuntungannya adalah dapat dibaca (dan, dengan pelatihan, tertulis) oleh non-pengembang - yaitu, pemangku kepentingan Anda dapat melihat daftar perilaku yang telah Anda tetapkan untuk menyelesaikan tugas dengan sukses dan melihat apakah itu sesuai dengan harapan mereka jauh sebelum Anda merilis produk yang tidak lengkap.

Ada bahasa scripting, yang dikenal sebagai Gherkin, yang sangat mirip dengan di atas dan memungkinkan Anda untuk menulis kode uji di belakang klausa dalam perilaku ini. Anda harus mencari penerjemah berbasis Gherkin untuk kerangka kerja pengembangan Anda yang biasa. Itu di luar cakupan jawaban ini.

Pokoknya, kembali ke perilaku. Aplikasi Anda saat ini belum melakukan ini (jika itu mengapa seseorang meminta perubahan?), Jadi Anda gagal dalam tes ini, apakah Anda menggunakan pelari ujian atau hanya menguji secara manual.

Jadi sekarang saatnya untuk beralih ke siklus TDD untuk menyediakan fungsionalitas itu.

Apakah Anda sedang menulis BDD atau tidak, tes Anda harus dinamai dengan sintaksis umum. Salah satu yang paling umum adalah sintaks "harus" yang Anda gambarkan.

Tulis tes: ShouldAcceptValidDetails. Lewati siklus Red-Green-Refactor sampai Anda puas. Apakah sekarang kita lulus tes perilaku? Jika tidak, tulis tes lain: ShouldRedirectToUserDefaultPage. Merah-Hijau-Refactor sampai Anda bahagia. Cuci, bilas, ulangi sampai Anda memenuhi kriteria yang ditetapkan dalam perilaku.

Dan kemudian kita beralih ke perilaku selanjutnya.

Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"

Sekarang Anda seharusnya tidak mendahului ini untuk melewati perilaku Anda sebelumnya. Anda harus gagal dalam tes ini pada saat ini. Jadi jatuhkan kembali ke siklus TDD Anda.

Dan seterusnya sampai Anda memiliki halaman Anda.

Sangat merekomendasikan The Rspec Book untuk mempelajari lebih lanjut tentang BDD dan TDD, bahkan jika Anda bukan pengembang Ruby.


Bisakah Anda memberikan komentar? Saya masih belum mengerti ...
Sayang

4

Pemahaman saya tentang itu:

  • BDD dimulai sebagai rebranding dari TDD untuk membuat fokus pada perilaku menjadi lebih jelas.
  • Ini memberikan lebih banyak dukungan formal (DSL dan tooling) untuk fokus pada perilaku dan spesifikasi yang dapat dieksekusi.
  • BDD sekarang dapat dilihat sebagai superset dari TDD,. Ini telah tumbuh dari waktu ke waktu untuk mencakup lebih dari persyaratan elisitasi sisi hal, tetapi masih sisi proses pengembangan adalah bagian inti dari itu.

Jadi untuk mengatasi TDD dilakukan dengan benar bagian dari BDD. BDD dimulai sebagai perubahan bahasa TDD untuk memperjelas maksud proses. Artikel pengantar Dan North tentang BDD menjelaskan mengapa memfokuskan pada kata behaviour daripada tes itu berguna - ini membantu mengonfirmasi bahwa Anda tidak hanya membangun perangkat lunak yang tepat, Anda juga membangun perangkat lunak yang tepat. Ini selalu menjadi bagian dari pendekatan TDD yang baik, tetapi Dan mengkodifikasinya sedikit menjadi BDD.


Apa yang saya pikir BDD buat sedikit lebih eksplisit daripada TDD, atau paling tidak formalisasi dan menyediakan dukungan alat, adalah pendekatan dua siklus / double loop / zoom-in zoom-out / outside-in. Anda pertama-tama menggambarkan perilaku fitur yang diharapkan (loop luar), kemudian memperbesar ke loop dalam untuk berurusan dengan spesifikasi tingkat rendah.

Doubleloop TDD Dari http://www.metesreau.com/ncraft-workshop/

Gherkin bersama dengan alat-alat seperti Mentimun dan SpecFlow menyediakan cara untuk menulis spesifikasi fitur tingkat tinggi tersebut dan kemudian menghubungkannya ke kode yang mengeksekusi kode aplikasi. Saya berpendapat bahwa ini adalah di mana BDD mungkin 'merasa' berbeda dari TDD, tetapi masih benar-benar melakukan hal yang sama, hanya dengan beberapa dukungan alat tambahan dan DSL. Agak lebih dekat dengan 'tradisional' TDD menggunakan alat seperti rspec, nspec, spock. Ini terasa sedikit lebih seperti proses yang sama yang Anda lakukan dalam TDD 'tradisional' tetapi dengan bahasa yang lebih berfokus pada perilaku.

Dalam BDD in Action oleh John Ferguson Smart (sangat disarankan), ia menganjurkan untuk pendekatan loop ganda, dimulai dengan sesuatu seperti jBehave pada spesifikasi yang dapat dieksekusi tingkat luar, kemudian jatuh ke alat seperti Spock untuk spesifikasi tingkat rendah.


BDD membawa konsep uji-didorong lebih dekat dengan para pemangku kepentingan bisnis. Gherkin dirancang agar dapat dibaca oleh bisnis, dan ide 'dokumentasi hidup', yaitu laporan kemajuan yang dihasilkan secara otomatis dari spesifikasi yang dapat dieksekusi adalah tentang memberikan umpan balik kepada para pemangku kepentingan.

Bagian lain dari BDD sekarang, di mana ia benar-benar menjadi sesuatu yang menggabungkan TDD sebagai bagian dari proses yang lebih besar, adalah persyaratan bit-bit elisitasi. Ide-ide seperti Injeksi Fitur, Pemetaan Dampak, dan Opsi Nyata adalah bagian dari sisi ini.

Untuk jawaban kanonik tentang ini, mungkin lebih baik pergi ke Dan North lagi . Jika tim Anda adalah semua pengembang, maka BDD = TDD. Jika tim Anda melibatkan seluruh jajaran pemangku kepentingan, BDD lebih dekat ke XP, dengan TDD menjadi salah satu bagiannya.


2

Apa hubungan BDD dan TDD?

Mereka adalah hal yang sama.

Dari apa yang saya mengerti BDD menambahkan dua hal utama di atas TDD: tes penamaan (pastikan / harus)

Itu bukan sesuatu yang BDD "tambahkan". Hanya saja konvensi berbeda yang dimaksudkan untuk membuatnya lebih mudah untuk mengajar dan memahami TDD.

Orang-orang yang menciptakan BDD semuanya mengajar TDD, dan mereka memperhatikan bahwa hal yang paling sulit untuk dipahami adalah bahwa TDD sama sekali tidak ada hubungannya dengan pengujian. Begitu siswa mengatasi rintangan itu, itu menjadi jauh lebih mudah bagi mereka. Tapi, sangat sulit untuk menceraikan diri Anda dari berpikir tentang pengujian , ketika kata "test" (atau terminologi terkait seperti "menegaskan") muncul praktis di mana - mana . Jadi, mereka mengubah beberapa kata.

Tapi itu hanya kata-kata! Tidak ada perbedaan aktual antara TDD dan BDD.

dan tes penerimaan.

Tes penerimaan sama pentingnya dengan TDD seperti halnya BDD. Sekali lagi: tidak ada perbedaan antara TDD dan BDD: TDD yang dilakukan dengan benar adalah BDD, BDD adalah yang dilakukan dengan benar.


Dalam hal apa tes penerimaan merupakan bagian penting dari TDD?
SiberianGuy

@ Idsa: mereka penting karena kode Anda tidak boleh lulus tes yang menurut Anda harus lulus, tetapi tes yang seharusnya dilakukan oleh kode. Saya pikir terlalu banyak orang yang bingung dengan hal ini, bahwa sebagian besar unit test tingkat rendah dan karenanya menghindari masalah yang sulit dalam menguji apa yang ditulis sistem untuk dilakukan secara keseluruhan.
gbjbaanb

@Idsa: Dengan cara yang sama mereka penting untuk BDD, tentu saja, karena keduanya adalah hal yang sama ! Tes penerimaan mendorong siklus luar TDD, yang berhubungan dengan fitur dan pengguna, berbeda dengan siklus dalam yang lebih rinci yang berkaitan dengan API dan protokol dan semacamnya. Saya pikir Kent Beck menyebutnya "Zoom In / Zoom Out". Anda dapat, misalnya, dengan mudah melihat ini di test suite JUnit, yang mungkin mengandung paling tidak sebanyak tes penerimaan karena mengandung tes unit.
Jörg W Mittag

Tes penerimaan adalah bagian penting dari TDD dan BDD. Tetapi mengatakan bahwa BDD sama dengan TDD sama dengan mengatakan TDD sama dengan tes pertama. Kecuali jika Anda mengizinkan tes untuk mendorong kode Anda, Anda tidak melakukan TDD (Saya dulu kenal seseorang yang senang menulis tes di depan tetapi berpendapat bahwa kode harus selalu ditulis seperti seharusnya jika Anda tidak menulis unit tes dan tes harus ditulis sesuai). Demikian juga, kecuali Anda membiarkan perilaku mendorong tes Anda, Anda tidak melakukan BDD.
pdr

1
@Idsa: Catatan bahwa ada banyak yang salah deskripsi TDD, yang tidak termasuk tes penerimaan. Deskripsi yang - sayangnya cukup populer dan cukup banyak diajarkan - deskripsi yang salah adalah salah satu alasan mengapa orang BDD berpikir itu mungkin ide yang baik untuk mengubah nama TDD dengan nama yang berbeda, untuk menghindari kebingungan. Namun demikian, dan itu tidak dapat diulang cukup sering, TDD dan BDD adalah hal yang persis sama .
Jörg W Mittag
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.