BDD (pembangunan yang didorong oleh tingkah laku) adalah kaedah pembangunan yang bekerjasama untuk memastikan perisian memenuhi keperluan pengguna. Ia menerangkan tingkah laku aplikasi melalui bahasa semulajadi untuk memudahkan komunikasi antara pemaju, penguji dan pihak perniagaan. Inti adalah untuk menulis senario ujian yang boleh dilaksanakan dalam format yang diberikan-kemudian, baik sebagai dokumen dan sebagai ujian automatik, supaya setiap orang mempunyai konsensus mengenai "lengkap" sebelum fungsi selesai. BDD didasarkan pada TDD tetapi memberi tumpuan lebih kepada tingkah laku pengguna dan hasil sistem, dan menggunakan alat seperti timun dan JBehave untuk mencapai sokongan silang bahasa. Sesuai untuk projek yang memerlukan keperluan yang sangat kolaboratif dan kompleks, tetapi mungkin tidak terpakai dalam pasukan dengan perubahan kecil atau kerjasama yang lemah. 1. Menekankan tingkah laku dan bukannya butiran teknikal; 2. Tentukan fungsi dari perspektif pengguna; 3. Senario yang boleh dilaksanakan sepanjang proses pembangunan; 4. Menyokong integrasi berterusan dan pengesanan kesilapan awal; 5. Berjaya bergantung pada kerjasama yang baik dan penulisan senario yang jelas.

Pembangunan yang didorong oleh tingkah laku (BDD) adalah pendekatan pembangunan perisian yang menyatukan pemaju, penguji, dan pihak berkepentingan perniagaan untuk membina perisian yang lebih baik memenuhi keperluan pengguna. Daripada memberi tumpuan semata -mata kepada kod atau spesifikasi teknikal, BDD menekankan kerjasama dan komunikasi yang jelas mengenai tingkah laku aplikasi - apa yang harus dilakukan dari perspektif pengguna.

Bagaimanakah BDD berfungsi dalam amalan?

Pada terasnya, BDD bermula dengan menentukan tingkah laku menggunakan senario mudah dan mudah dibaca. Ini biasanya ditulis dalam format yang diberikan, yang menjadikan mereka mudah untuk kedua-dua orang teknikal dan bukan teknikal untuk memahami.

Contohnya:

• Diberikan saya log masuk ke akaun saya
• Semasa saya menambah item ke troli saya
• Maka kiraan kereta harus meningkat oleh satu

Senario ini menjadi kedua -dua dokumentasi dan ujian automatik. Pemaju kemudian menulis kod yang memenuhi tingkah laku ini, dan ujian dijalankan secara berterusan untuk memastikan segala -galanya masih berfungsi seperti yang diharapkan.

Ini membantu mengelakkan salah faham dan membuat semua orang sejajar dengan apa yang sebenarnya dilakukan oleh perisian.

Mengapa menggunakan BDD bukan hanya TDD atau ujian biasa?

Pembangunan yang didorong oleh ujian (TDD) memfokuskan pada ujian unit menulis sebelum kod, tetapi ujian tersebut boleh menjadi sukar bagi bukan pemaju untuk diikuti. BDD membina TDD dengan memindahkan tumpuan kepada tingkah laku pengguna dan hasil sistem, bukan hanya logik dalaman.

Beberapa perbezaan utama:

• BDD menggunakan senario bahasa biasa (sering sintaks gherkin), menjadikannya lebih mudah diakses
• Ia menggalakkan kerjasama awal antara pasukan dan pihak berkepentingan
• Ujian terikat secara langsung kepada ciri dan keperluan pengguna, bukan hanya fungsi

Ini bermakna kejutan yang lebih sedikit apabila perisian dilakukan - kerana semua orang bersetuju dengan apa yang "dilakukan" kelihatan seperti pendahuluan.

Alat biasa yang digunakan di BDD

Terdapat beberapa alat yang menyokong amalan BDD di pelbagai bahasa pengaturcaraan:

• Timun - Salah satu alat yang paling popular, menyokong pelbagai bahasa termasuk Java, Ruby, dan JavaScript
• JBehave - Direka untuk projek Java, mengintegrasikan dengan baik dengan rangka kerja ujian yang sedia ada
• Berkelakuan (python) - rangka kerja BDD untuk python yang menyokong sintaks gherkin
• SpecFlow - digunakan secara meluas dalam persekitaran .NET

Alat ini membantu menjadikan senario tingkah laku anda menjadi ujian yang boleh dilaksanakan. Mereka juga menjana laporan dan mengintegrasikan dengan saluran paip CI/CD supaya anda boleh menguji dan menangkap isu secara automatik.

Semasa BDD berfungsi dengan baik (dan ketika tidak)

BDD bersinar dalam persekitaran di mana komunikasi penting - terutamanya apabila pemilik produk, QA, dan pemaju perlu tetap sejajar. Ia hebat untuk ciri -ciri kompleks atau domain di mana keperluan salah faham boleh membawa kepada kerja semula yang mahal.

Tetapi ia tidak semestinya sesuai:

• Untuk perubahan yang sangat kecil atau cepat, overhead mungkin tidak berbaloi
• Pasukan tanpa tabiat kerjasama yang baik mungkin berjuang untuk mendapatkan nilai dari BDD
• Menulis senario yang baik mengambil amalan - yang kurang ditulis boleh menyebabkan kekeliruan dan bukannya kejelasan

Jika pasukan anda terbuka untuk meningkatkan komunikasi dan meletakkan beberapa usaha untuk menulis senario yang baik, BDD boleh membuat membina ciri -ciri yang betul berasa lebih lancar.

Pada dasarnya itu sahaja.

Atas ialah kandungan terperinci Apakah pembangunan yang didorong oleh tingkah laku bdd. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!