BDD: Memulai

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?

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.

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 .

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.