BDD: Memulai


9

Saya mulai dengan BDD dan ini adalah cerita saya:

Feature: Months and days to days
    In order to see months and days as days
    As a date conversion fan
    I need a webpage where users can enter
    days and months and convert them to days.

Saya ragu ...

Haruskah saya menulis skenario saya sebelum mengkode sesuatu atau saya harus menulis skenario dan kemudian menulis kode, menulis skenario lagi dan kemudian menulis kode, dan seterusnya ...?

Jika saya harus menulis skenario saya sebelumnya, dapatkah langkah saya disetujui dan kode produksi masih belum selesai?

Kapan saya harus melakukan refactoring pada kode saya? Setelah fitur selesai atau setelah setiap implementasi skenario?


"Bisakah langkah saya disetujui dan kode produksi masih belum selesai?" Apa artinya ini? Tolong jelaskan.
S.Lott

Jawaban:


12

Dari cerita itu, saya menyimpulkan bahwa Anda mengkode sendiri.

Biasanya tujuan BDD adalah untuk memungkinkan percakapan, khususnya antara bisnis dan pengembang, sehingga tim dapat yakin bahwa mereka telah mencapai pemahaman bersama. Kami juga ingin menyertakan penguji, karena mereka dapat melihat ketika kami melewatkan skenario.

Jika Anda melakukannya sendiri, ambil bebek karet dan jelaskan perilaku aplikasi Anda pada bebek itu. Berikan beberapa contoh cara kerjanya. Itu akan menjadi skenario Anda.

Untuk memulainya, saya sarankan untuk tidak mengotomatiskan skenario tersebut. Anda dapat menuliskannya jika Anda mau. Ingatlah bahwa hasil bisnis yang Anda bagikan dengan bebek adalah tentang tingkat yang tepat untuk memasukkannya. Anda sekarang harus memiliki gagasan tentang bagaimana aplikasi itu berperilaku, dan Anda dapat menjalankan melalui skenario secara manual. Saya suka memperlakukan semua yang belum berfungsi seperti bug . Saya kadang - kadang mulai dengan otomatisasi, tetapi hanya ketika saya tahu betul bagaimana sistem bekerja, saya akrab dengan alat-alat, dan UI dipahami dengan baik. Bahkan kemudian saya sering harus memperbaikinya sedikit ketika saya sudah menulis kode.

Pada level yang lebih rendah, beri tahu bebek Anda bagaimana setiap kelas akan berperilaku. Berikan beberapa contoh. Bebek karet sangat mampu memahami bahasa teknis. Sekarang Anda memiliki BDD unit-level Anda, alias unit test. Siklus red-green-refactor terjadi di sini. (Saya cenderung tidak perlu refactor lagi, karena saya memikirkan tanggung jawab kelas saya, mengutarakannya dalam bahasa yang berorientasi bisnis, dan itu cenderung rontok dengan cara yang sangat indah. Tapi saya Sudah melakukan ini untuk sementara waktu sekarang. Tidak masalah jika Anda melakukannya.)

Jangan terlalu banyak refactor. Kami masih ingin mendapatkan umpan balik tentang kode kami, karena selalu ada hal-hal yang tidak kami ketahui yang tidak kami ketahui . Kesempurnaan adalah musuh Anda di sini. Buatlah itu cukup bagus, buatlah itu bisa dibaca, lalu lanjutkan. Jika Anda perlu membuat sesuatu yang sempurna untuk membuat perubahan lebih lanjut, lakukan saat Anda membuat perubahan lebih lanjut.

Jika Anda memiliki kesempatan untuk mendapatkan umpan balik tentang skenario Anda dari para pemangku kepentingan bisnis, tetapi mereka tidak puas dengan Anda, Anda dapat mengirim skenario kepada mereka segera setelah Anda menulisnya, dan sebelum Anda mengotomatisasi mereka. Anda mungkin ingin mengirim mock-up UI juga, sehingga mereka dapat menghubungkan kata-kata dengan tindakan. Jangan terlalu jauh dari coding dengan ini. Bekerjalah dengan asumsi bahwa apa yang telah Anda lakukan salah , dan Anda perlu mendapatkan umpan balik untuk mengetahui caranya.

Sebagai satu petunjuk terakhir, biasanya jangan mengutarakan cerita dari sudut pandang pengguna (skenario, ya, tapi bukan cerita). Itu bukan cerita pengguna. Mungkin harus membaca sesuatu seperti:

In order to attract people to my website
As @thom
I want users to easily convert months and days to days.

Ada beberapa tujuan tingkat yang lebih tinggi yang Anda cari. Ini juga akan membantu Anda menggambarkan kemampuan yang Anda butuhkan. Semoga berhasil, dan minta maaf untuk posting ekstra panjang.


1
Bagian 'bebek karet' sangat bagus. Saya pikir saya adalah satu-satunya yang akan memikirkan itu!
NoChance

3

Haruskah saya menulis skenario saya sebelum mengkode sesuatu atau saya harus menulis skenario dan kemudian menulis kode, menulis skenario lagi dan kemudian menulis kode, dan seterusnya ...?

Keduanya akan bekerja. Pilih salah satu.

Tidak masalah.

Semakin banyak skenario yang Anda miliki, semakin banyak desain yang dapat Anda lakukan di muka.

Semakin banyak skenario yang Anda miliki, semakin lama waktu yang dibutuhkan untuk menyelesaikan sesuatu.

Kapan saya harus melakukan refactoring pada kode saya? Setelah fitur selesai atau setelah setiap implementasi skenario?

Tidak. Anda refactor ketika menjadi sulit untuk merancang skenario berikutnya .


Saya telah membuat pertanyaan baru ... "Jika saya harus menulis skenario saya sebelum ...". Bolehkah Anda melihatnya? Terima kasih banyak.
thom

1
@ S.Lott Jawaban yang bagus tetapi satu berdalih: berdasarkan kegunaan siklus refactor merah-hijau, saya akan menyarankan refactoring terus menerus selama proses BDD, tepat setelah setiap tes hijau.
Rein Henrichs

@Rein Henrichs: Alternatif lain adalah mencatat bahwa refactoring untuk menyelesaikan semua tes untuk satu cerita terjadi sebagai bagian yang tidak terhindarkan dan tak terhindarkan dari pengkodean. Bahkan desain yang bagus tidak dapat mencakup semua pangkalan. Refactoring itu sepertinya tidak layak disebut. Namun, Anda memang menunjukkannya dengan baik. Refactoring antara cerita, bagaimanapun, adalah operasi yang lebih serius dan memakan waktu, karena set fitur berkembang oleh pertambahan cerita.
S.Lott

3

Gunakan kata kerja deskriptif

Feature: CONVERT Months and days to days

Jangan membuat keputusan desain dalam cerita ["Saya butuh halaman web" adalah keputusan desain]

As a date conversion fan
I want to convert days and months into days

Gunakan sasaran nilai bisnis dalam cerita

So that [some business reason]

Tulis sebanyak mungkin fitur dan cerita sebelum Anda mulai membuat kode; cerita saling menginformasikan , mempengaruhi fitur, dan menginformasikan desain.

Refactor setelah setiap cerita. Merah-Hijau-Reaktor.


+1, jawaban yang bagus. Tapi bukankah "cara BDD" untuk refactor sebagai bagian dari siklus tes unit dalam daripada siklus tes penerimaan luar?
pdr

@ pdr: itulah yang saya maksud, refactor setelah setiap cerita. BDD / TDD menguji skala dari unit ke penerimaan, hanya ada satu siklus (dalam pikiran saya) ;-)
Steven A. Lowe

Mengapa "Saya butuh laman web" adalah keputusan desain? Terima kasih!
thom

@thom: cerita pengguna harus mengungkapkan apa yang ingin dapat dilakukan oleh pengguna, bukan bagaimana itu akan diterapkan. Dengan kata lain, fitur, cerita, dan skenario adalah persyaratan dan spesifikasi fungsional. Jangan membuat keputusan desain sampai Anda memiliki gambaran lengkap. Dalam contoh (mungkin buatan) ini, kebutuhan bisnis pengguna secara keseluruhan dapat mengindikasikan bahwa halaman web mungkin bukan solusi yang paling nyaman - widget desktop atau aplikasi seluler mungkin lebih baik, tergantung pada bagaimana / kapan mereka perlu menggunakannya. Detail implementasi mengacaukan cerita, dan mungkin mengunci Anda ke dalam desain spesifik terlalu cepat.
Steven A. Lowe
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.