BDD - Pengembangan Berbasis Tes
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 menghemat 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 Test-Last 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, sering 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 uji Unit. Jadi, metodologi ini menggunakan pengujian Unit untuk mendorong pengembangan.
Hal mendasar yang perlu diperhatikan bahwa tujuannya adalah pengembangan berdasarkan pengujian.
Siklus Refaktor 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 mengungkapkan 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 kepercayaan diri untuk membuat perubahan apa pun karena jika perubahan berdampak pada fungsionalitas yang ada, hal yang sama terungkap dengan menjalankan pengujian dan kerusakan dapat segera diperbaiki.
Pada setiap uji coba yang berturut-turut, 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 lulus, TDD akan ditambahkan ke Automation Test Suite karena semua tes perlu dijalankan setiap kali kode baru ditambahkan atau kode yang sudah 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, baru dalam pengiriman perangkat lunak gesit. Seiring waktu, BDD telah berkembang untuk mencakup gambaran yang lebih luas tentang analisis gesit 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