Behavior Driven Development - Panduan Cepat

Behavior Driven Development (BDD) adalah proses pengembangan perangkat lunak yang awalnya muncul dari Test Driven Development (TDD).

Menurut Dan North, yang bertanggung jawab atas evolusi BDD, "BDD menggunakan contoh di berbagai tingkat untuk menciptakan pemahaman bersama dan memunculkan ketidakpastian guna menghadirkan perangkat lunak yang penting."

BDD menggunakan contoh-contoh untuk menggambarkan perilaku sistem yang ditulis dalam bahasa yang dapat dibaca dan dimengerti untuk semua orang yang terlibat dalam pengembangan. Contoh-contoh ini termasuk -

Dikonversi menjadi spesifikasi yang dapat dieksekusi.
Digunakan sebagai tes penerimaan.

BDD - Fitur utama

Pengembangan yang Didorong Perilaku berfokus pada -

Menyediakan proses bersama dan alat bersama yang mempromosikan komunikasi kepada pengembang perangkat lunak, analis bisnis, dan pemangku kepentingan untuk berkolaborasi dalam pengembangan perangkat lunak, dengan tujuan memberikan produk dengan nilai bisnis.
Apa yang harus dilakukan oleh sistem dan bukan pada bagaimana seharusnya diterapkan.
Memberikan keterbacaan dan visibilitas yang lebih baik.
Memverifikasi tidak hanya kerja perangkat lunak tetapi juga memenuhi harapan pelanggan.

Asal BDD

Biaya untuk memperbaiki cacat bertambah berlipat ganda jika cacat tidak terdeteksi pada waktu yang tepat dan diperbaiki saat terdeteksi. Perhatikan contoh berikut.

Hal ini menunjukkan bahwa kecuali persyaratan diperoleh dengan benar, akan mahal untuk memperbaiki cacat akibat kesalahpahaman persyaratan di tahap selanjutnya. Lebih lanjut, produk akhir mungkin tidak memenuhi harapan pelanggan.

Kebutuhan saat ini adalah pendekatan pengembangan yang -

Didasarkan pada persyaratan.
Berfokus pada persyaratan selama pengembangan.
Memastikan bahwa persyaratan terpenuhi.

Pendekatan pengembangan yang dapat memenuhi persyaratan yang disebutkan di atas adalah BDD. Jadi, Perkembangan Berbasis Perilaku -

Memperoleh contoh berbagai perilaku yang diharapkan dari sistem.
Memungkinkan penulisan contoh dalam bahasa menggunakan istilah domain bisnis untuk memastikan pemahaman yang mudah oleh semua orang yang terlibat dalam pengembangan termasuk pelanggan.
Mendapatkan contoh yang diratifikasi dengan pelanggan dari waktu ke waktu melalui percakapan.
Berfokus pada kebutuhan pelanggan (contoh) selama pengembangan.
Menggunakan contoh sebagai tes penerimaan.

Praktek BDD

Dua praktik utama BDD adalah -

Spesifikasi dengan Contoh (SbE)
Test Driven Development (TDD)

Spesifikasi dengan Contoh

Spesifikasi dengan Contoh (SbE) menggunakan contoh dalam percakapan untuk menggambarkan aturan bisnis dan perilaku perangkat lunak yang akan dibangun.

Spesifikasi dengan Contoh memungkinkan pemilik produk, analis bisnis, penguji dan pengembang untuk menghilangkan kesalahpahaman umum tentang persyaratan bisnis.

Pengembangan Berbasis Tes

Test Driven Development, dalam konteks BDD, mengubah contoh menjadi spesifikasi yang dapat dieksekusi dan dapat dibaca manusia.

Pengembang menggunakan spesifikasi ini sebagai panduan untuk menerapkan peningkatan fungsionalitas baru. Ini, menghasilkan basis kode yang ramping dan serangkaian uji regresi otomatis yang menjaga biaya pemeliharaan tetap rendah selama masa pakai perangkat lunak.

BDD tangkas

Dalam pengembangan perangkat lunak Agile, metode BDD digunakan untuk mencapai pemahaman umum tentang spesifikasi yang tertunda.

Langkah-langkah berikut dijalankan di Agile BDD -

Pengembang dan pemilik produk secara kolaboratif menulis spesifikasi yang menunggu keputusan dalam editor teks biasa.
Pemilik produk menentukan perilaku yang mereka harapkan dari sistem.
Para pengembang
- Isi spesifikasi dengan detail perilaku berikut.
- Ajukan pertanyaan berdasarkan pemahaman mereka tentang sistem.
Perilaku sistem saat ini dianggap untuk melihat apakah fitur baru akan merusak salah satu fitur yang ada.

Manifesto Agile dan BDD

The Agile Manifesto menyatakan berikut ini -

Kami menemukan cara yang lebih baik untuk mengembangkan perangkat lunak dengan melakukannya dan membantu orang lain melakukannya. Melalui pekerjaan ini, kami menjadi menghargai -

Individuals and interactions - Lebih dari Proses dan alat
Working software - Lebih dari dokumentasi Komprehensif
Customer collaboration - Lebih dari negosiasi kontrak
Responding to change - over Mengikuti rencana

Artinya, meskipun ada nilai di item di sebelah kanan, kami lebih menghargai item di sebelah kiri.

BDD menyelaraskan dirinya dengan manifesto Agile sebagai berikut -

Manifesto Agile	Penyelarasan BDD
Individu dan interaksi atas proses dan alat.	BDD adalah tentang melakukan percakapan.
Bekerja perangkat lunak di atas dokumentasi yang komprehensif.	BDD berfokus untuk memudahkan pembuatan perangkat lunak yang bernilai bisnis.
Kolaborasi pelanggan melalui negosiasi kontrak.	BDD berfokus pada skenario berdasarkan ide-ide dengan komunikasi berkelanjutan dengan pelanggan seiring perkembangan kemajuan. Itu tidak didasarkan pada janji apa pun.
Menanggapi perubahan mengikuti rencana.	BDD berfokus pada komunikasi dan kolaborasi berkelanjutan yang memfasilitasi penyerapan perubahan.

Saat Anda melihat referensi apa pun tentang Behavior Driven Development, Anda akan menemukan penggunaan frasa seperti "BDD diturunkan dari TDD", "BDD dan TDD". Untuk mengetahui bagaimana BDD muncul, mengapa dikatakan diturunkan dari TDD dan apa itu BDD dan TDD, Anda harus memiliki pemahaman tentang TDD.

Mengapa Menguji?

Untuk memulai, mari kita masuk ke dasar-dasar pengujian. Tujuan pengujian adalah untuk memastikan bahwa sistem yang dibangun berfungsi sesuai dengan yang diharapkan. Perhatikan contoh berikut.

Oleh karena itu, berdasarkan pengalaman kami telah belajar bahwa menemukan cacat saat dan ketika diperkenalkan dan segera memperbaikinya akan hemat biaya. Oleh karena itu, ada kebutuhan untuk menulis kasus uji pada setiap tahap pengembangan dan pengujian. Inilah yang diajarkan oleh praktik pengujian tradisional kami, yang sering disebut sebagai Test-early.

Pendekatan pengujian ini disebut sebagai pendekatan Uji-Terakhir karena pengujian dilakukan setelah selesainya suatu tahap.

Tantangan dengan Pendekatan Uji-Terakhir

Pendekatan Test-Last diikuti selama beberapa waktu dalam proyek pengembangan perangkat lunak. Namun, pada kenyataannya, dengan pendekatan ini, karena pengujian harus menunggu hingga tahap tertentu selesai, sering kali hal itu terlewatkan karena -

Penundaan dalam penyelesaian tahapan.
Jadwal waktu yang ketat.
Fokus pada pengiriman tepat waktu, melewati pengujian.

Lebih lanjut, dalam pendekatan Test-Last, Pengujian unit, yang seharusnya dilakukan oleh pengembang, seringkali dilewati. Berbagai alasan yang ditemukan didasarkan pada pola pikir para pengembang -

Mereka adalah pengembang dan bukan penguji.
Pengujian adalah tanggung jawab penguji.
Mereka efisien dalam pengkodean dan kodenya tidak akan cacat.

Ini menghasilkan -

Berkompromi pada kualitas produk yang dikirim.
Memiliki akuntabilitas kualitas hanya pada penguji.
Biaya tinggi dalam memperbaiki cacat, setelah pengiriman.
Ketidakmampuan untuk mendapatkan kepuasan pelanggan, yang juga berarti hilangnya bisnis yang berulang, sehingga mempengaruhi kredibilitas.

Faktor-faktor ini membutuhkan pergeseran paradigma, untuk fokus pada pengujian. Hasilnya adalah pendekatan Test-First.

Pendekatan Uji-Pertama

Pendekatan Test-First menggantikan cara pengembangan inside-out (tulis kode dan kemudian uji) menjadi outside-in (uji tulis dan kemudian kode).

Pendekatan ini digabungkan ke dalam metodologi pengembangan perangkat lunak berikut (yang juga Agile) -

eXtreme Programming (XP).
TEst Dterbelah Development (TDD).

Dalam metodologi ini, pengembang merancang dan menulis tes Unit untuk modul kode sebelum menulis satu baris modul kode. Pengembang kemudian membuat modul kode dengan tujuan lulus tes Unit. Jadi, metodologi ini menggunakan pengujian Unit untuk mendorong pengembangan.

Hal mendasar yang perlu diperhatikan bahwa tujuannya adalah pengembangan berdasarkan pengujian.

Siklus Refactor Merah-Hijau

Test Driven Development digunakan untuk mengembangkan kode yang dipandu oleh pengujian Unit.

Step 1 - Pertimbangkan modul kode yang akan ditulis.

Step 2 - Tulis tes

Step 3 - Jalankan tesnya.

Tes gagal, karena kodenya masih belum tertulis. Oleh karena itu, Langkah 2 biasanya disebut sebagai tes tulis gagal.

Step 4 - Tulis kode seminimal mungkin untuk lulus ujian.

Step 5- Jalankan semua tes untuk memastikan bahwa semuanya masih lulus. Tes unit diotomatiskan untuk memfasilitasi langkah ini.

Step 6 - Refactor.

Step 7 - Ulangi Langkah 1 hingga Langkah 6 untuk modul kode berikutnya.

Setiap siklus harus sangat singkat, dan jam biasanya harus berisi banyak siklus.

Ini juga dikenal sebagai Red-Green-Refactor siklus, dimana -

Red - Menulis tes yang gagal.
Green - Menulis kode untuk lulus ujian.
Refactor - Hapus duplikasi dan perbaiki kode ke standar yang dapat diterima.

Langkah-langkah Proses TDD

Langkah-langkah proses TDD diilustrasikan di bawah ini.

Keuntungan TDD

Manfaat atau keuntungan dari Test Driven Development adalah -

Pengembang perlu memahami terlebih dahulu, apa hasil yang diinginkan dan bagaimana mengujinya sebelum membuat kode.
Kode untuk sebuah komponen selesai hanya jika tes berhasil dan kode tersebut difaktorkan ulang. Ini memastikan pengujian dan pemfaktoran ulang sebelum pengembang melanjutkan ke pengujian berikutnya.
Karena rangkaian pengujian Unit dijalankan setelah setiap pemfaktoran ulang, umpan balik bahwa setiap komponen masih berfungsi konstan.
Tes Unit bertindak sebagai dokumentasi hidup yang selalu sesuai dengan data.
Jika cacat ditemukan, pengembang membuat tes untuk mengungkap cacat itu dan kemudian memodifikasi kode sehingga tes lolos dan cacat diperbaiki. Ini mengurangi waktu debugging. Semua tes lainnya juga dijalankan dan ketika mereka lulus, itu memastikan bahwa fungsionalitas yang ada tidak rusak
Pengembang dapat membuat keputusan desain dan refactor kapan saja dan menjalankan pengujian memastikan bahwa sistem masih berfungsi. Ini membuat perangkat lunak dapat dipelihara.
Pengembang memiliki keyakinan untuk membuat perubahan apa pun karena jika perubahan berdampak pada fungsionalitas yang ada, hal yang sama akan terungkap dengan menjalankan pengujian dan kerusakan dapat segera diperbaiki.
Pada setiap uji coba yang berurutan, semua perbaikan kerusakan sebelumnya juga diverifikasi dan pengulangan kerusakan yang sama berkurang.
Karena sebagian besar pengujian dilakukan selama pengembangan itu sendiri, pengujian sebelum pengiriman dipersingkat.

Kekurangan TDD

Titik awalnya adalah User Stories, yang menjelaskan perilaku sistem. Karenanya, para pengembang sering menghadapi pertanyaan berikut -

Kapan harus menguji?
Apa yang harus diuji?
Bagaimana cara mengetahui apakah suatu spesifikasi terpenuhi?
Apakah kode tersebut memberikan nilai bisnis?

Kesalahpahaman tentang TDD

Kesalahpahaman berikut ada di industri dan perlu klarifikasi.

Kesalahpahaman	Klarifikasi
TDD adalah tentang pengujian dan otomatisasi pengujian.	TDD merupakan metodologi pengembangan yang menggunakan pendekatan Test-First.
TDD tidak melibatkan desain apa pun.	TDD mencakup analisis kritis dan desain berdasarkan kebutuhan. Desain muncul selama pengembangan.
TDD hanya di level Unit.	TDD dapat digunakan pada tingkat integrasi dan sistem.
TDD tidak dapat digunakan oleh proyek pengujian tradisional.	TDD menjadi populer dengan Extreme Programming dan digunakan dalam metodologi Agile lainnya. Namun, ini juga dapat digunakan dalam proyek pengujian tradisional.
TDD adalah alat.	TDD adalah metodologi pengembangan, dan setelah setiap Tes Unit baru berlalu, TDD akan ditambahkan ke Automation Test Suite karena semua tes perlu dijalankan setiap kali kode baru ditambahkan atau kode yang ada diubah dan juga setelah setiap refactoring. Dengan demikian, Alat Otomasi Uji yang mendukung TDD memfasilitasi proses ini.
TDD berarti menyerahkan tes Penerimaan kepada pengembang.	TDD tidak berarti menyerahkan Tes Penerimaan kepada pengembang.

Penerimaan TDD

Acceptance Test Driven Development (ATDD) mendefinisikan Kriteria Penerimaan dan Tes Penerimaan selama pembuatan Kisah Pengguna, di awal pengembangan. ATDD berfokus pada komunikasi dan pemahaman bersama di antara pelanggan, pengembang, dan penguji.

Praktik utama dalam ATDD adalah sebagai berikut -

Diskusikan skenario dunia nyata untuk membangun pemahaman bersama tentang domain.
Gunakan skenario tersebut untuk sampai pada kriteria penerimaan.
Otomatiskan tes Penerimaan.
Fokuskan pengembangan pada tes tersebut.
Gunakan pengujian sebagai spesifikasi langsung untuk memfasilitasi perubahan.

Manfaat menggunakan ATDD adalah sebagai berikut -

Persyaratan tidak ambigu dan tanpa celah fungsional.
Yang lain memahami kasus khusus yang diramalkan oleh pengembang.
Tes Penerimaan memandu pengembangan.

TDD Vs BDD

Menurut Dan North, programmer biasanya menghadapi masalah berikut saat melakukan Test Driven Development -

Mulai dari mana
Apa yang harus diuji dan apa yang tidak diuji
Berapa banyak yang harus diuji dalam sekali jalan
Apa yang disebut tes mereka
Bagaimana memahami mengapa tes gagal

Solusi untuk semua masalah ini adalah Behavior Driven Development. Ini telah berkembang dari praktik agile yang sudah mapan dan dirancang untuk membuatnya lebih mudah diakses dan efektif untuk tim, yang baru dalam pengiriman perangkat lunak gesit. Seiring waktu, BDD telah berkembang untuk mencakup gambaran yang lebih luas tentang analisis tangkas dan pengujian penerimaan otomatis.

Utama difference between TDD and BDD apakah itu -

TDD menjelaskan cara kerja perangkat lunak.
Di sisi lain, BDD -
- Menjelaskan bagaimana pengguna akhir menggunakan perangkat lunak.
- Memupuk kolaborasi dan komunikasi.
- Menekankan pada contoh perilaku Sistem.
- Bertujuan pada spesifikasi yang dapat dieksekusi yang berasal dari contoh

Dalam TDD, istilah "Tes Penerimaan" menyesatkan. Tes penerimaan sebenarnya mewakili perilaku yang diharapkan dari sistem. Dalam praktik Agile, kolaborasi seluruh tim dan interaksi dengan pelanggan dan pemangku kepentingan lainnya ditekankan. Hal ini memunculkan kebutuhan akan penggunaan istilah yang mudah dipahami oleh semua orang yang terlibat dalam proyek.

TDD membuat Anda berpikir tentang yang dibutuhkan Behavior dan karenanya istilah 'Perilaku' lebih berguna daripada istilah itu ‘Test’. BDD adalah Test Driven Development dengan kosakata yang berfokus pada perilaku dan bukan tes.

Dalam kata-kata Dan North, "Saya menemukan pergeseran dari berpikir dalam ujian ke berpikir dalam perilaku begitu dalam sehingga saya mulai menyebut TDD sebagai BDD, atau Pengembangan Berbasis Perilaku." TDD berfokus pada bagaimana sesuatu akan bekerja, BDD berfokus pada mengapa kita membangunnya.

BDD menjawab pertanyaan-pertanyaan berikut yang sering dihadapi oleh para pengembang -

Pertanyaan	Menjawab
Mulai dari mana?	luar-dalam
Apa yang harus diuji?	Kisah Pengguna
Apa yang tidak untuk diuji?	ada yang lain

Jawaban-jawaban ini menghasilkan kerangka cerita sebagai berikut -

Story Framework

Sebagai [Role]

saya ingin [Feature]

yang seperti itu [Benefit]

Artinya, 'When a Feature dijalankan, hasilnya Benefit adalah bagi Orang yang memainkan Role.'

BDD selanjutnya menjawab pertanyaan-pertanyaan berikut -

Pertanyaan	Menjawab
Berapa banyak yang harus diuji dalam sekali jalan?	sangat sedikit fokus
Apa yang menyebut tes mereka?	template kalimat
Bagaimana memahami mengapa tes gagal	dokumentasi

Jawaban ini menghasilkan kerangka Contoh sebagai berikut -

Example Framework

Given beberapa konteks awal,

When sebuah peristiwa terjadi,

Then memastikan beberapa hasil.

Artinya, 'Dimulai dengan konteks awal, ketika peristiwa tertentu terjadi, kita tahu apa hasilnya should be. '

Jadi, contoh menunjukkan perilaku yang diharapkan dari sistem. Contoh tersebut digunakan untuk mengilustrasikan berbagai skenario sistem.

Cerita dan Skenario

Mari kita perhatikan ilustrasi berikut oleh Dan North tentang sistem ATM.

Cerita

As a pelanggan,

I want untuk menarik uang tunai dari ATM,

so that Saya tidak perlu mengantri di bank.

Skenario

Ada dua kemungkinan skenario untuk cerita ini.

Scenario 1 - Akun sedang dalam kredit

Given akun tersebut dalam kredit

And kartu tersebut valid

And dispenser berisi uang tunai

When pelanggan meminta uang tunai

Then pastikan akun didebit

And memastikan uang tunai dibagikan

And pastikan kartu tersebut dikembalikan

Scenario 2 - Rekening ditarik melebihi batas cerukan

Given akunnya terlalu banyak

And kartu tersebut valid

When pelanggan meminta uang tunai

Then pastikan pesan penolakan ditampilkan

And memastikan uang tunai tidak dibagikan

And pastikan kartu tersebut dikembalikan

Peristiwa tersebut sama di kedua skenario, tetapi konteksnya berbeda. Oleh karena itu, hasilnya berbeda.

Siklus Pengembangan

Siklus Pengembangan untuk BDD adalah outside-in pendekatan.

Step 1- Tulis contoh nilai bisnis tingkat tinggi (di luar) (menggunakan Mentimun atau RSpec / Kapibara) yang menjadi merah. (RSpec menghasilkan kerangka kerja BDD dalam bahasa Ruby)

Step 2 - Tulis contoh RSpec level bawah (di dalam) untuk langkah pertama implementasi yang menjadi merah.

Step 3 - Menerapkan kode minimum untuk meneruskan contoh tingkat yang lebih rendah itu, melihatnya menjadi hijau.

Step 4 - Tulis contoh RSpec tingkat bawah berikutnya yang mendorong untuk melewati Langkah 1 yang menjadi merah.

Step 5 - Ulangi langkah Langkah 3 dan Langkah 4 hingga contoh tingkat tinggi di Langkah 1 menjadi hijau.

Note - Poin-poin berikut harus diingat -

Red/green negara adalah status izin.
Jika pengujian tingkat rendah Anda berwarna hijau, Anda memiliki izin untuk menulis contoh baru atau memfaktor ulang implementasi yang ada. Anda tidak boleh, dalam konteks refactoring, menambahkan fungsionalitas / fleksibilitas baru.
Jika pengujian tingkat rendah Anda berwarna merah, Anda memiliki izin untuk menulis atau mengubah kode implementasi hanya untuk membuat pengujian yang ada menjadi hijau. Anda harus menahan keinginan untuk menulis kode agar lulus tes berikutnya, yang tidak ada, atau menerapkan fitur yang menurut Anda bagus (pelanggan tidak akan bertanya).

Menurut Gojko Adzic, penulis 'Spesifikasi dengan Contoh', Spesifikasi dengan Contoh adalah sekumpulan pola proses yang memfasilitasi perubahan dalam produk perangkat lunak untuk memastikan bahwa produk yang tepat dikirimkan secara efisien. ”

Spesifikasi dengan Contoh adalah pendekatan kolaboratif untuk menentukan persyaratan dan tes fungsional berorientasi bisnis untuk produk perangkat lunak berdasarkan menangkap dan menggambarkan persyaratan menggunakan contoh realistis, bukan pernyataan abstrak.

Spesifikasi dengan Contoh - Gambaran Umum

Tujuan dari Spesifikasi dengan Contoh adalah untuk fokus pada pengembangan dan penyampaian persyaratan bisnis yang diprioritaskan dan dapat diverifikasi. Sementara konsep Spesifikasi dengan Contoh itu sendiri relatif baru, ini hanyalah pengungkapan ulang dari praktik yang ada.

Ini mendukung kosakata singkat yang sangat spesifik yang dikenal sebagai bahasa di mana-mana yang -

Mengaktifkan persyaratan yang dapat dieksekusi.
Digunakan oleh semua orang di tim.
Dibuat oleh tim lintas fungsi.
Menangkap pemahaman semua orang.

Spesifikasi dengan Contoh dapat digunakan sebagai masukan langsung ke dalam membangun pengujian Otomatis yang mencerminkan domain bisnis. Jadi, fokus dari Spesifikasi dengan Contoh adalah membangun produk yang tepat dan membangun produk yang benar.

Tujuan Spesifikasi dengan Contoh

Tujuan utama dari Spesifikasi dengan Contoh adalah untuk membangun produk yang tepat. Ini berfokus pada pemahaman bersama, sehingga membangun satu sumber kebenaran. Ini memungkinkan otomatisasi kriteria penerimaan sehingga fokusnya adalah pada pencegahan cacat daripada deteksi cacat. Ini juga mempromosikan tes lebih awal untuk menemukan cacat lebih awal.

Penggunaan SbE

Spesifikasi dengan Contoh digunakan untuk menggambarkan perilaku sistem yang diharapkan yang menggambarkan nilai bisnis. Ilustrasinya adalah dengan menggunakan contoh nyata dan nyata. Contoh ini digunakan untuk membuat persyaratan yang dapat dieksekusi yaitu -

Dapat diuji tanpa terjemahan.
Diambil dalam dokumentasi langsung.

Berikut adalah alasan mengapa kami menggunakan contoh untuk menjelaskan spesifikasi tertentu -

Mereka lebih mudah dimengerti.
Mereka lebih sulit untuk disalahartikan.

Keuntungan SbE

Keuntungan menggunakan Spesifikasi dengan Contoh adalah -

Peningkatan kualitas
Mengurangi limbah
Mengurangi risiko cacat produksi
Upaya terfokus
Perubahan bisa dilakukan dengan lebih aman
Keterlibatan bisnis yang lebih baik

Aplikasi SbE

Spesifikasi dengan Contoh temukan aplikasi di -

Baik bisnis yang kompleks atau organisasi yang kompleks.
Tidak bekerja dengan baik untuk masalah teknis semata.
Tidak berfungsi dengan baik untuk produk perangkat lunak yang berfokus pada UI.
Dapat diterapkan ke sistem lama juga.

SbE dan Pengujian Penerimaan

Keuntungan Spesifikasi dengan Contoh dalam hal pengujian Penerimaan adalah -

Satu ilustrasi tunggal digunakan untuk keduanya, persyaratan rinci dan pengujian
Kemajuan proyek dalam hal tes Penerimaan -
- Setiap tes untuk menguji suatu perilaku.
- Sebuah tes bisa berarti lulus untuk suatu perilaku atau tidak.
- Tes kelulusan menunjukkan bahwa perilaku tertentu telah diselesaikan.
- Jika sebuah proyek yang membutuhkan 100 perilaku untuk diselesaikan memiliki 60 perilaku yang diselesaikan, maka 60% sudah selesai.
Penguji beralih dari perbaikan cacat ke pencegahan cacat, dan mereka berkontribusi pada desain solusi.
Otomasi memungkinkan pemahaman instan tentang dampak perubahan persyaratan pada solusi.

Spesifikasi dengan Contoh - Apa artinya untuk Peran yang berbeda

Tujuan dari Spesifikasi dengan Contoh adalah untuk mempromosikan kolaborasi semua orang dalam tim, termasuk pelanggan di seluruh proyek untuk memberikan nilai bisnis. Setiap orang untuk pemahaman yang lebih baik menggunakan Kosakata yang sama.

Wewenang	Penggunaan SbE
Analis Bisnis	Persyaratan tidak ambigu dan tanpa celah fungsional. Pengembang, sebenarnya membaca spesifikasinya.
Pengembang	Pengembang lebih memahami apa yang sedang dikembangkan. Kemajuan pengembangan dilacak lebih baik dengan menghitung spesifikasi yang telah dikembangkan dengan benar.
Penguji	Penguji memahami lebih baik, apa yang sedang diuji. Penguji dilibatkan sejak awal dan memiliki peran dalam desain. Penguji bekerja untuk mencegah kerusakan daripada mendeteksi kerusakan.
Semua orang	Waktu dihemat dengan mengidentifikasi kesalahan dari awal. Produk berkualitas dihasilkan dari awal.

SbE - Satu Set Pola Proses

Seperti yang telah kita lihat di awal bab ini, Spesifikasi dengan Contoh didefinisikan sebagai sekumpulan pola proses yang memfasilitasi perubahan dalam produk perangkat lunak untuk memastikan bahwa produk yang tepat dikirimkan secara efisien.

Pola prosesnya adalah -

Spesifikasi kolaboratif
Mengilustrasikan spesifikasi menggunakan contoh
Menyempurnakan spesifikasi
Mengotomatiskan contoh
Sering memvalidasi
Dokumentasi hidup

Spesifikasi Kolaboratif

Tujuan spesifikasi kolaboratif adalah untuk -

Dapatkan berbagai peran dalam tim untuk memiliki pemahaman yang sama dan kosakata bersama.
Libatkan semua orang dalam proyek sehingga mereka dapat menyumbangkan perspektif mereka yang berbeda tentang suatu fitur.
Pastikan komunikasi dan kepemilikan fitur bersama.

Sasaran ini terpenuhi dalam lokakarya spesifikasi yang juga dikenal sebagai pertemuan Three Amigos. Tiga Amigos adalah BA, QA dan pengembang. Meskipun ada peran lain dalam proyek, ketiganya akan bertanggung jawab dan dapat dipertanggungjawabkan mulai dari definisi hingga penyampaian fitur.

During the meeting −

Business Analyst (BA) menyajikan persyaratan dan pengujian untuk fitur baru.
Ketiga Amigos (BA, Pengembang, dan QA) membahas fitur baru dan meninjau spesifikasinya.
QA dan pengembang juga mengidentifikasi persyaratan yang hilang.
Tiga Amigos
- Memanfaatkan model bersama menggunakan bahasa di mana-mana.
- Gunakan kosakata domain (Daftar istilah dipertahankan jika diperlukan).
- Cari perbedaan dan konflik.
Jangan langsung ke detail implementasi pada saat ini.
Capai konsensus tentang apakah suatu fitur telah ditentukan secara memadai.
Rasa persyaratan yang sama dan kepemilikan pengujian memfasilitasi spesifikasi kualitas
Persyaratan disajikan sebagai skenario, yang memberikan persyaratan yang eksplisit dan tidak ambigu. Skenario adalah contoh perilaku sistem dari sudut pandang pengguna.

Spesifikasi Ilustrasi menggunakan Contoh

Skenario ditentukan menggunakan struktur Diberikan-Ketika-Kemudian untuk membuat spesifikasi yang dapat diuji -

Given <beberapa prasyarat>

And <prasyarat tambahan> Optional

When <tindakan / pemicu terjadi>

Then <beberapa kondisi posting>

And <ketentuan posting tambahan> Optional

Spesifikasi ini adalah contoh perilaku sistem. Ini juga mewakili kriteria Penerimaan sistem.

Tim mendiskusikan contoh dan umpan balik dimasukkan sampai ada kesepakatan bahwa contoh mencakup perilaku fitur yang diharapkan. Ini memastikan cakupan tes yang baik.

Memperbaiki Spesifikasi

Untuk memperbaiki spesifikasi,

Tuliskan contoh dengan tepat. Jika sebuah contoh berubah menjadi kompleks, bagi menjadi beberapa contoh yang lebih sederhana.
Fokus pada perspektif bisnis dan hindari detail teknis.
Pertimbangkan kondisi positif dan negatif.
Patuhi kosakata khusus domain.
Diskusikan contoh dengan pelanggan.
- Pilih percakapan untuk mencapai ini.
- Pertimbangkan hanya contoh-contoh yang diminati pelanggan. Ini memungkinkan produksi kode yang diperlukan saja dan menghindari mencakup setiap kemungkinan kombinasi, yang mungkin tidak diperlukan
Untuk memastikan bahwa skenario berhasil, semua kasus uji untuk skenario itu harus lulus. Karenanya, tingkatkan spesifikasi agar dapat diuji. Kasus uji dapat mencakup berbagai rentang dan nilai data (kasus batas dan sudut) serta aturan bisnis yang berbeda yang mengakibatkan perubahan data.
Tentukan aturan bisnis tambahan seperti penghitungan kompleks, manipulasi / transformasi data, dll.
Sertakan skenario non-fungsional (mis. Kinerja, beban, kegunaan, dll.) Sebagai Spesifikasi berdasarkan Contoh

Mengotomatiskan Contoh

Lapisan otomasi perlu dibuat sangat sederhana - cukup kabel spesifikasi ke sistem yang diuji. Anda dapat menggunakan alat untuk hal yang sama.

Lakukan otomatisasi pengujian menggunakan Domain Specific Language (DSL) dan tunjukkan koneksi yang jelas antara input dan output. Fokus pada spesifikasi, bukan skrip. Pastikan pengujian tersebut tepat, mudah dipahami, dan dapat diuji.

Sering Memvalidasi

Sertakan contoh validasi dalam pipeline pengembangan Anda dengan setiap perubahan (penambahan / modifikasi). Ada banyak teknik dan alat yang dapat (dan harus) diadopsi untuk membantu memastikan kualitas suatu produk. Mereka berputar di sekitar tiga prinsip utama-Test Early, Test Well dan Test Often.

Jalankan pengujian secara rutin sehingga Anda dapat mengidentifikasi tautan yang lemah. Contoh yang mewakili perilaku membantu melacak kemajuan dan perilaku dikatakan selesai hanya setelah lulus tes terkait.

Dokumentasi Hidup

Pertahankan spesifikasi sesederhana dan sesingkat mungkin. Atur spesifikasi dan kembangkan seiring kemajuan pekerjaan. Jadikan dokumentasi dapat diakses oleh semua orang dalam tim.

Spesifikasi dengan Contoh Langkah Proses

Ilustrasi menunjukkan langkah-langkah proses dalam Spesifikasi dengan Contoh.

Anti-pola

Anti-pola adalah pola tertentu dalam pengembangan perangkat lunak yang dianggap sebagai praktik pemrograman yang buruk. Berbeda dengan pola desain, yang merupakan pendekatan umum untuk masalah umum, yang telah diformalkan dan secara umum dianggap sebagai praktik pengembangan yang baik, anti-pola adalah sebaliknya dan tidak diinginkan

Anti-pola menimbulkan berbagai masalah.

Anti-pola	Masalah
Tidak ada kolaborasi	Banyak asumsi Membangun hal yang salah Menguji hal yang salah Tidak tahu kapan kode selesai
Tidak tahu kapan kode selesai	Sulit untuk mempertahankan tes Sulit untuk memahami spesifikasi Kehilangan minat dari perwakilan bisnis
Contoh yang terlalu detail atau terlalu terpusat pada UI	Sulit untuk mempertahankan tes Sulit untuk memahami spesifikasinya Kehilangan minat dari perwakilan bisnis
Diperlukan upaya meremehkan	Tim berpikir mereka telah gagal dan kecewa lebih awal

Solusi untuk Masalah - Kualitas

Kualitas dapat dipastikan dengan mengawasi anti-pola. Untuk meminimalkan masalah yang diciptakan oleh anti-pola, Anda harus -

Berkumpullah untuk menentukan menggunakan contoh.
Bersihkan dan tingkatkan contoh.
Tulis kode yang memenuhi contoh
Otomatiskan contoh dan terapkan.
Ulangi pendekatan untuk setiap cerita pengguna.

Untuk mengatasi masalah karena anti-pola berarti kepatuhan pada -

Collaboration.
Berfokus pada apa.
Berfokus pada Bisnis.
Dipersiapkan.

Mari kita pahami apa arti masing-masing di atas.

Kolaborasi

Bekerja sama -

Para pelaku bisnis, pengembang dan penguji memberikan masukan dari sudut pandang mereka masing-masing.
Contoh otomatis membuktikan bahwa tim telah membangun hal yang benar.
Prosesnya lebih berharga daripada tes itu sendiri.

Berfokus pada apa

Anda harus fokus pada pertanyaan - 'apa'. Sambil fokus pada 'apa' -

Jangan mencoba untuk menutupi semua kemungkinan kasus.
Jangan lupa untuk menggunakan jenis tes yang berbeda.
Buat contoh sesederhana mungkin.
Contoh harus mudah dimengerti oleh pengguna sistem.
Alat seharusnya tidak memainkan peran penting dalam bengkel.

Berfokus pada Bisnis

Untuk fokus pada bisnis -

Pertahankan spesifikasi pada tujuan bisnis.
Sertakan bisnis dalam membuat dan meninjau spesifikasi.
Sembunyikan semua detail di lapisan otomatisasi.

Dipersiapkan

Bersiaplah untuk yang berikut -

Manfaat tidak segera terlihat, bahkan saat latihan tim diubah.
Memperkenalkan SbE itu menantang.
Membutuhkan waktu dan investasi.
Pengujian otomatis tidak gratis.

Alat

Penggunaan alat tidak wajib untuk Spesifikasi dengan Contoh, meskipun dalam praktiknya beberapa alat tersedia. Ada kasus yang berhasil mengikuti Spesifikasi dengan Contoh bahkan tanpa menggunakan alat.

Alat berikut mendukung Spesifikasi dengan Contoh -

Cucumber
SpecFlow
Fitnesse
Jbehave
Concordion
Behat
Jasmine
Relish
Speclog

Tim pengembang sering kali salah paham bahwa BDD adalah kerangka kerja alat. Pada kenyataannya, BDD adalah pendekatan pengembangan daripada kerangka alat. Namun, seperti dalam kasus pendekatan pembangunan lainnya, ada juga alat untuk BDD.

Beberapa Alat BDD digunakan untuk berbagai platform dan bahasa pemrograman. Mereka adalah -

Mentimun (kerangka Ruby)
SpecFlow (.NET framework)
Berperilaku (kerangka Python)
JBehave (kerangka Java)
JBehave Web (kerangka Java dengan integrasi Selenium)
Selada (kerangka Python)
Konkordion (kerangka Java)
Behat (kerangka PHP)
Kahlan (kerangka PHP)
DaSpec (kerangka JavaScript)
Jasmine (kerangka JavaScript)
Cucumber-js (kerangka JavaScript)
Squish GUI Tester (Alat Pengujian GUI BDD untuk JavaScript, Python, Perl, Ruby dan Tcl)
Spock (kerangka Groovy)
Yadda (dukungan bahasa Gherkin untuk kerangka kerja seperti Jasmine (kerangka JavaScript))

Timun

Mentimun adalah alat gratis untuk spesifikasi yang dapat dieksekusi yang digunakan secara global. Cucumber memungkinkan tim pengembangan perangkat lunak menjelaskan bagaimana perangkat lunak harus berperilaku dalam teks biasa. Teks tersebut ditulis dalam bahasa domain tertentu yang dapat dibaca bisnis dan berfungsi sebagai dokumentasi, tes otomatis, dan bantuan pengembangan, semuanya digabung ke dalam satu format. Anda dapat menggunakan lebih dari empat puluh bahasa lisan yang berbeda (Inggris, Cina, dll.) Dengan Ketimun.

Mentimun - Fitur Utama

Fitur utama Mentimun adalah sebagai berikut -

Mentimun dapat digunakan untuk Spesifikasi yang Dapat Dieksekusi, Otomasi Tes, dan Dokumentasi Hidup.
Mentimun bekerja dengan Ruby, Java, NET, Flex, atau aplikasi web yang ditulis dalam bahasa apa pun.
Mentimun mendukung Tes yang lebih ringkas dalam Tabel - mirip dengan yang dilakukan FIT.
Mentimun telah merevolusi Siklus Hidup Pengembangan Perangkat Lunak dengan menggabungkan persyaratan, pengujian otomatis, dan dokumentasi menjadi satu kesatuan: spesifikasi yang dapat dieksekusi teks biasa yang memvalidasi perangkat lunak.

SpecFlow

SpecFlow adalah Alat BDD untuk .NET Platform. SpecFlow adalah proyek sumber terbuka. Kode sumber dihosting di GitHub.

SpecFlow menggunakan Sintaks Gherkin untuk Fitur. Format Gherkin diperkenalkan oleh Ketimun dan juga digunakan oleh alat lain. Bahasa Gherkin dipertahankan sebagai proyek di GitHub -https://github.com/cucumber/gherkin

Bertingkah

Behave digunakan untuk kerangka Python.

Behave bekerja dengan tiga jenis file yang disimpan dalam direktori yang disebut "fitur" -
- fitur file dengan skenario perilaku Anda di dalamnya.
- Direktori "langkah" dengan implementasi langkah Python untuk skenario.
- Secara opsional, beberapa kontrol lingkungan (kode untuk dijalankan sebelum dan sesudah langkah, skenario, fitur, atau seluruh pertandingan pengambilan gambar).
Fitur Behave ditulis menggunakan Gherkin (dengan beberapa modifikasi) dan diberi nama "name.feature".
Tag yang dilampirkan ke fitur dan skenario tersedia di fungsi lingkungan melalui objek "fitur" atau "skenario" yang diteruskan kepadanya. Pada objek tersebut terdapat atribut bernama “tags” yang merupakan daftar nama-nama tag yang dilampirkan, sesuai urutan keberadaannya di file fitur.
Modifikasi pada Standar Gherkin -
- Behave dapat mengurai file Gherkin standar dan memperluas Gherkin untuk memungkinkan kata kunci langkah huruf kecil karena ini terkadang memungkinkan spesifikasi fitur yang lebih mudah dibaca

Selada

Selada adalah alat BDD yang sangat sederhana berdasarkan Ketimun. Itu dapat mengeksekusi deskripsi fungsional teks biasa sebagai tes otomatis untuk proyek Python. Selada bertujuan untuk melakukan tugas-tugas yang paling umum pada BDD.

Konkordion

Concordion adalah alat open source untuk mengotomatiskan Spesifikasi dengan Contoh untuk Kerangka Java.

Meskipun fitur intinya sederhana, API kerangka kerja ekstensi yang kuat memungkinkan Anda menambahkan fungsionalitas, seperti menggunakan spreadsheet Excel sebagai spesifikasi, menambahkan tangkapan layar ke keluaran, menampilkan informasi pencatatan, dll.

Konkordion memungkinkan Anda menulis spesifikasi dalam bahasa normal menggunakan paragraf, tabel, dan tanda baca yang tepat, sedangkan Bahasa terstruktur menggunakan Given / When / Then tidak diperlukan.

Konkordi telah diporting ke bahasa lain termasuk -

C # (Concordion.NET)
Python (PyConcordion)
Ruby (Ruby-Concordion)

Mentimun adalah alat yang mendukung spesifikasi Executable, otomatisasi Tes, dan dokumentasi Hidup.

Behavior Driven Development memperluas Spesifikasi dengan Contoh. Ini juga memformalkan praktik terbaik Test-Driven Development, khususnya, perspektif bekerja dari luar ke dalam. Pekerjaan pengembangan didasarkan pada spesifikasi yang dapat dijalankan.

Itu key features spesifikasi yang dapat dieksekusi adalah sebagai berikut -

Spesifikasi yang Dapat Dijalankan adalah -
- Berasal dari contoh, yang merepresentasikan perilaku sistem.
- Ditulis dengan kolaborasi semua yang terlibat dalam pembangunan, termasuk bisnis dan pemangku kepentingan.
- Berdasarkan kriteria penerimaan.
Uji penerimaan yang didasarkan pada spesifikasi yang dapat dijalankan dilakukan secara otomatis.
Bahasa bersama di mana-mana digunakan untuk menulis spesifikasi yang dapat dieksekusi dan pengujian otomatis sedemikian rupa sehingga -
- Terminologi khusus domain digunakan selama pengembangan.
- Setiap orang, termasuk pelanggan dan pemangku kepentingan berbicara tentang sistem, persyaratannya, dan implementasinya, dengan cara yang sama.
- Istilah yang sama digunakan untuk membahas sistem yang ada dalam persyaratan, dokumen desain, kode, pengujian, dll.
- Siapa pun dapat membaca dan memahami persyaratan dan cara membuat lebih banyak persyaratan.
- Perubahan dapat dengan mudah diakomodasi.
- Dokumentasi langsung dipertahankan.

Mentimun membantu proses ini karena ia mengikat spesifikasi yang dapat dijalankan dengan kode aktual sistem dan tes penerimaan otomatis.

Cara melakukannya sebenarnya dirancang untuk membuat pelanggan dan pengembang bekerja sama. Apabila lolos uji penerimaan, berarti spesifikasi perilaku sistem yang diwakilinya telah dilaksanakan dengan benar.

Tes Penerimaan Mentimun Khas

Perhatikan contoh berikut.

Feature − Sign up

Pendaftaran harus cepat dan ramah.
Skenario - Pendaftaran berhasil
- New pengguna harus mendapatkan email konfirmasi dan disambut secara pribadi.
- Given Saya telah memilih untuk mendaftar.
- When Saya mendaftar dengan detail yang valid.
- Then Saya akan menerima email konfirmasi.
- And Saya akan melihat pesan ucapan pribadi.

Dari contoh ini, kita dapat melihat bahwa -

Tes penerimaan mengacu pada Features.
Fitur dijelaskan oleh Scenarios.
Skenario terdiri dari Steps.

Spesifikasi ditulis dalam bahasa alami dalam file teks biasa, tetapi dapat dieksekusi.

Bekerja dari Mentimun

Mentimun adalah alat baris perintah yang memproses file teks yang berisi fitur yang mencari skenario yang dapat dijalankan terhadap sistem Anda. Mari kita pahami cara kerja Ketimun.

Itu menggunakan banyak konvensi tentang bagaimana file diberi nama dan di mana mereka berada (folder masing-masing) untuk membuatnya mudah untuk memulai.
Mentimun memungkinkan Anda menyimpan spesifikasi, tes otomatis, dan dokumentasi di tempat yang sama.
Setiap skenario adalah daftar langkah-langkah yang menjelaskan prakondisi, tindakan, dan pascakondisi skenario; jika setiap langkah dijalankan tanpa kesalahan apa pun, skenario akan ditandai sebagai lulus.
Di akhir lari, Mentimun akan melaporkan berapa banyak skenario yang dilewati.
Jika ada yang gagal, ini memberikan informasi tentang apa yang gagal sehingga pengembang dapat melanjutkan.

Di Mentimun, Features, Scenarios, dan Langkah-langkah ditulis dalam Bahasa yang disebut Gherkin.

Gherkin adalah bahasa Inggris teks biasa (atau salah satu dari 60+ bahasa lain) dengan struktur. Gherkin mudah dipelajari dan strukturnya memungkinkan Anda menulis contoh secara ringkas.

Mentimun menjalankan file Anda yang berisi spesifikasi yang dapat dieksekusi yang tertulis di Gherkin.
Mentimun membutuhkan Definisi Langkah untuk menerjemahkan Gherkin Steps teks biasa menjadi tindakan yang akan berinteraksi dengan sistem.
Saat Mentimun menjalankan langkah dalam skenario, ia akan mencari definisi langkah yang cocok untuk dieksekusi.
Definisi Langkah adalah potongan kecil kode dengan pola yang melekat padanya.
Pola ini digunakan untuk menautkan Definisi Langkah ke semua langkah yang cocok, dan kodenya adalah apa yang akan dijalankan Mentimun saat melihat langkah Gherkin.
Setiap langkah disertai dengan Definisi Langkah.
Sebagian besar langkah akan mengumpulkan masukan dan kemudian mendelegasikan ke kerangka kerja yang khusus untuk domain aplikasi Anda untuk membuat panggilan pada kerangka Anda.

Mentimun mendukung lebih dari selusin platform perangkat lunak yang berbeda. Anda dapat memilih penerapan Mentimun yang sesuai untuk Anda. Setiap implementasi Ketimun menyediakan fungsionalitas keseluruhan yang sama dan mereka juga memiliki prosedur instalasi dan fungsionalitas khusus platform sendiri.

Pemetaan Langkah dan Definisi Langkah

Kunci Mentimun adalah pemetaan antara Langkah dan Definisi Langkah.

Penerapan Mentimun

Diberikan di bawah ini adalah implementasi Mentimun.

	Ruby / JRuby
	JRuby (menggunakan Cucumber-JVM)
	Jawa
	Groovy
	.NET (menggunakan SpecFlow)
	JavaScript
	JavaScript (menggunakan Cucumber-JVM dan Rhino)
	Clojure
	Gosu
	Lua
	PHP (menggunakan Behat)
	Jython
	C ++
	Tcl

Integrasi Kerangka

Diberikan di bawah ini adalah implementasi Kerangka.

	Ruby on Rails
	Selenium
	PicoContainer
	Kerangka Musim Semi
	Watir

Gherkin adalah bahasa yang digunakan untuk menulis Features, Scenarios, and Steps. Tujuan Gherkin adalah membantu kami menulis persyaratan konkret.

Untuk memahami apa yang kami maksud dengan persyaratan konkret, perhatikan contoh berikut -

Pelanggan harus dicegah memasukkan rincian kartu kredit yang tidak valid.

Melawan

Jika pelanggan memasukkan nomor kartu kredit yang panjangnya tidak tepat 16 digit, ketika mereka mencoba mengirimkan formulir, nomor itu harus ditampilkan ulang dengan pesan kesalahan yang memberi tahu mereka tentang jumlah digit yang benar.

Yang terakhir tidak memiliki ambiguitas dan menghindari kesalahan dan jauh lebih dapat diuji.

Gherkin dirancang untuk menciptakan persyaratan yang lebih konkret. Di Gherkin, contoh di atas terlihat seperti -

Feature

Umpan balik ketika memasukkan rincian kartu kredit yang tidak valid Feature Definition

Dalam pengujian pengguna, kami telah melihat banyak orang yang melakukan kesalahan Dokumentasi

Background True for all Scenarios Below

Given Saya telah memilih item untuk dibeli,

And Saya akan memasukkan nomor kartu kredit saya

Scenario - Nomor kartu kredit terlalu pendekScenario Definition

When Saya memasukkan nomor kartu yang panjangnya kurang dari 16 digit

And semua detail lainnya benar

And Saya mengirimkan formulirSteps

Then formulir harus ditampilkan kembali

And Saya akan melihat pesan yang memberi tahu saya tentang jumlah digit yang benar

Format dan Sintaks Gherkin

File Gherkin adalah File teks biasa dan memiliki ekstensi .feature. Setiap baris yang tidak kosong harus diawali dengan kata kunci Gherkin, diikuti dengan teks yang Anda suka. Kata kuncinya adalah -

Feature
Scenario
Diberikan, Kapan, Lalu, Dan, Tapi (Langkah)
Background
Skenario Outline
Examples
"" "(Doc Strings)
| (Tabel Data)
@ (Tag)
# (Komentar)
*

Fitur

Itu FeatureKata kunci digunakan untuk mendeskripsikan fitur perangkat lunak, dan untuk mengelompokkan skenario terkait. Fitur memiliki tiga elemen dasar -

Kata kunci - Fitur.
Nama fitur, disediakan di baris yang sama dengan kata kunci Fitur.
Deskripsi opsional (tetapi sangat disarankan) yang dapat menjangkau beberapa baris yaitu semua teks di antara baris yang berisi fitur kata kunci, dan baris yang dimulai dengan Skenario, Latar Belakang, atau Kerangka Skenario.

Selain nama dan deskripsi, Fitur berisi daftar skenario atau kerangka skenario, dan latar belakang opsional.

Adalah konvensional untuk menamai a .featurefile dengan mengambil nama Fitur, mengubahnya menjadi huruf kecil dan mengganti spasi dengan garis bawah. Sebagai contoh,

feedback_when_entering_invalid_credit_card_details.feature

Untuk mengidentifikasi Fitur di sistem Anda, Anda dapat menggunakan apa yang disebut sebagai "template injeksi fitur".

Untuk <memenuhi beberapa tujuan> sebagai <tipe pengguna> Saya menginginkan <a fitur>

Deskripsi

Beberapa bagian dari dokumen Gherkin tidak harus dimulai dengan kata kunci.

Pada baris setelah Fitur, skenario, kerangka skenario atau contoh, Anda dapat menulis apapun yang Anda suka, selama tidak ada baris yang dimulai dengan kata kunci. Ini adalah cara untuk memasukkan Deskripsi.

Skenario

Untuk mengekspresikan perilaku sistem Anda, Anda melampirkan satu atau lebih skenario dengan setiap Fitur. Biasanya melihat 5 hingga 20 skenario per Fitur untuk sepenuhnya menentukan semua perilaku di sekitar Fitur itu.

Skenario mengikuti pola berikut -

Jelaskan konteks awal
Jelaskan sebuah acara
Jelaskan hasil yang diharapkan

Kami mulai dengan konteks, mendeskripsikan tindakan, dan memeriksa hasilnya. Ini dilakukan dengan langkah-langkah. Gherkin memberikan tiga kata kunci untuk menjelaskan setiap konteks, tindakan, dan hasil sebagai langkah-langkah.

Given - Tetapkan konteks
When - Lakukan aksi
Then - Periksa hasilnya

Kata kunci ini memberikan pembacaan skenario.

Example

Scenario - Menarik uang dari akun.

Given Saya memiliki $ 100 di akun saya.
When Saya meminta $ 20.
Then $ 20 harus dibagikan.

Jika ada beberapa Given atau When langkah di bawah satu sama lain, Anda dapat menggunakan And atau But. Mereka memungkinkan Anda untuk menentukan skenario secara detail.

Example

Scenario - Coba penarikan menggunakan kartu curian.

Given Saya memiliki $ 100 di akun saya.
But kartu saya tidak valid.
When Saya meminta $ 50.
Then kartu saya tidak boleh dikembalikan.
And Saya harus diberitahu untuk menghubungi bank.

Saat membuat skenario, ingatlah 'setiap skenario harus masuk akal dan dapat dijalankan secara independen dari skenario lain' '. Artinya -

Anda tidak dapat memiliki kondisi sukses dari satu skenario bergantung pada fakta bahwa beberapa skenario lain telah dijalankan sebelumnya.
Setiap skenario membuat konteksnya sendiri, mengeksekusi satu hal, dan menguji hasilnya.

Skenario seperti itu memberikan manfaat berikut -

Tes akan lebih sederhana dan lebih mudah dipahami.
Anda dapat menjalankan hanya sebagian dari skenario Anda dan Anda tidak perlu khawatir tentang kerusakan set pengujian Anda.
Bergantung pada sistem Anda, Anda mungkin dapat menjalankan pengujian secara paralel, mengurangi jumlah waktu yang dibutuhkan untuk menjalankan semua pengujian Anda.

Skenario Outline

Jika Anda harus menulis skenario dengan beberapa input atau output, Anda mungkin akan membuat beberapa skenario yang hanya berbeda nilainya. Solusinya adalah dengan menggunakan garis besar skenario. Untuk menulis kerangka skenario,

Variabel dalam langkah kerangka skenario ditandai dengan <dan>.
Berbagai nilai variabel diberikan sebagai contoh dalam tabel.

Example

Misalkan Anda sedang menulis Fitur untuk menambahkan dua angka pada kalkulator.

Feature - Tambahkan.

Scenario Outline: Add two numbers.
Given the input "<input>"
When the calculator is run
Then the output should be <output>"
Examples
| input    | output |
| 2+2      | 4      | 
| 98+1     | 99     |
| 255+390  | 645    |

Bagian kerangka skenario selalu diikuti oleh satu atau beberapa bagian contoh, yang merupakan wadah untuk tabel. Tabel harus memiliki baris header yang sesuai dengan variabel dalam langkah-langkah kerangka skenario. Setiap baris di bawah ini akan membuat skenario baru, dengan mengisi nilai variabel

SpecFlow adalah proyek sumber terbuka. Kode sumber dihosting di GitHub. File fitur yang digunakan oleh SpecFlow untuk menyimpan kriteria penerimaan fitur (kasus penggunaan, cerita pengguna) dalam aplikasi Anda ditentukan menggunakan sintaks Gherkin.

Format Gherkin diperkenalkan oleh Ketimun dan juga digunakan oleh alat lain. Bahasa Gherkin dipertahankan sebagai proyek di GitHub -https://github.com/cucumber/gherkin

Elemen Fitur dan SpecFlow

Fitur utama dari elemen Fitur adalah -

Elemen fitur menyediakan header untuk file fitur. Elemen fitur menyertakan nama dan deskripsi tingkat tinggi dari fitur terkait dalam aplikasi Anda.
- SpecFlow menghasilkan kelas pengujian unit untuk elemen fitur, dengan nama kelas yang diambil dari nama fitur tersebut.
- SpecFlow menghasilkan pengujian unit yang dapat dieksekusi dari skenario yang mewakili kriteria penerimaan.
File fitur mungkin berisi beberapa skenario yang digunakan untuk mendeskripsikan pengujian penerimaan fitur.
- Skenario memiliki nama dan dapat terdiri dari beberapa langkah skenario.
- SpecFlow menghasilkan metode pengujian unit untuk setiap skenario, dengan nama metode yang diambil dari nama skenario.

Beberapa Langkah Skenario

Skenario dapat memiliki beberapa langkah skenario. Ada tiga jenis langkah yang menentukan prasyarat, tindakan atau langkah verifikasi, yang membentuk tes penerimaan.

Berbagai jenis langkah dimulai dengan file Given, When atau Then kata kunci masing-masing dan langkah selanjutnya dari jenis yang sama dapat ditautkan menggunakan And dan But kata kunci.
Sintaks Gherkin memungkinkan kombinasi apa pun dari ketiga jenis langkah ini, tetapi skenario biasanya memiliki blok yang berbeda Given, When dan Then pernyataan.
Langkah-langkah skenario ditentukan menggunakan teks dan dapat memiliki tabel tambahan yang disebut DataTable atau teks multi-baris yang disebut argumen DocString.
Langkah-langkah skenario adalah cara utama untuk menjalankan kode kustom apa pun untuk mengotomatiskan aplikasi.
SpecFlow menghasilkan panggilan di dalam metode pengujian unit untuk setiap langkah skenario. Panggilan ini dilakukan oleh runtime SpecFlow yang akan menjalankan definisi langkah yang cocok dengan langkah skenario.
Pencocokan dilakukan pada waktu proses, sehingga pengujian yang dihasilkan dapat dikompilasi dan dijalankan meskipun pengikatan belum diimplementasikan.
Anda dapat menyertakan tabel dan argumen multi-baris dalam langkah-langkah skenario. Ini digunakan oleh definisi langkah dan diteruskan sebagai tabel tambahan atau argumen string.

Garis Besar Skenario

Garis besar skenario dapat digunakan untuk menentukan tes penerimaan berdasarkan data. Kerangka skenario selalu terdiri dari spesifikasi template skenario (skenario dengan placeholder data menggunakan sintaks <placeholder>) dan sekumpulan contoh yang memberikan nilai untuk placeholder

Jika kerangka pengujian unit mendukungnya, SpecFlow menghasilkan pengujian berbasis baris dari kerangka skenario.
Jika tidak, ini menghasilkan metode logika pengujian unit berparameter untuk garis besar skenario dan metode pengujian unit individu untuk setiap kumpulan contoh.
Untuk ketertelusuran yang lebih baik, nama metode pengujian unit yang dihasilkan berasal dari judul kerangka skenario dan nilai pertama contoh (kolom pertama tabel contoh).
Oleh karena itu, praktik yang baik adalah memilih parameter unik dan deskriptif sebagai kolom pertama dalam kumpulan contoh.
Karena sintaks Gherkin memang mengharuskan semua kolom contoh memiliki placeholder yang cocok dalam kerangka skenario, Anda bahkan dapat memasukkan kolom arbitrer dalam kumpulan contoh yang digunakan untuk memberi nama pengujian dengan lebih mudah dibaca.
SpecFlow melakukan substitusi placeholder sebagai fase terpisah sebelum mencocokkan pengikatan langkah.
Implementasi dan parameter dalam pengikatan langkah dengan demikian tidak bergantung pada apakah keduanya dijalankan melalui skenario langsung atau kerangka skenario.
Ini memungkinkan Anda untuk menentukan contoh lebih lanjut dalam pengujian penerimaan nanti tanpa mengubah binding langkah.

Komentar

Anda dapat menambahkan baris komentar ke file fitur di mana saja dengan memulai baris dengan #. Namun berhati-hatilah, karena komentar dalam spesifikasi Anda dapat menjadi tanda bahwa kriteria penerimaan telah ditetapkan secara salah. SpecFlow mengabaikan baris komentar.