Apa itu Test Driven Development (TDD)? Tutorial dengan Contoh

Daftar Isi:

Anonim

Pengembangan Berbasis Tes

Test Driven Development (TDD) adalah pendekatan pengembangan perangkat lunak di mana kasus uji dikembangkan untuk menentukan dan memvalidasi apa yang akan dilakukan kode. Secara sederhana, kasus pengujian untuk setiap fungsionalitas dibuat dan diuji terlebih dahulu dan jika pengujian gagal maka kode baru ditulis untuk lulus pengujian dan membuat kode sederhana dan bebas bug.

Pengembangan Berbasis Pengujian dimulai dengan merancang dan mengembangkan pengujian untuk setiap fungsionalitas kecil aplikasi. TDD menginstruksikan pengembang untuk menulis kode baru hanya jika tes otomatis gagal. Ini untuk menghindari duplikasi kode. Bentuk lengkap TDD adalah pengembangan yang digerakkan oleh Tes.

Konsep sederhana dari TDD adalah menulis dan memperbaiki tes yang gagal sebelum menulis kode baru (sebelum pengembangan). Ini membantu untuk menghindari duplikasi kode saat kami menulis sejumlah kecil kode pada satu waktu untuk lulus tes. (Tes hanyalah kondisi persyaratan yang perlu kita uji untuk memenuhinya).

Pengembangan Test-Driven adalah proses mengembangkan dan menjalankan pengujian otomatis sebelum pengembangan aplikasi yang sebenarnya. Karenanya, TDD terkadang juga disebut sebagai Test First Development.

Dalam tutorial ini, Anda akan mempelajari lebih lanjut tentang-

  • Bagaimana melakukan Tes TDD
  • TDD Vs. Pengujian Tradisional
  • Apa penerimaan TDD dan TDD Pengembang
  • Penskalaan TDD melalui Agile Model Driven Development (AMDD)
  • Test Driven Development (TDD) Vs. Agile Model Driven Development (AMDD)
  • Contoh TDD
  • Manfaat TDD

Bagaimana melakukan Tes TDD

Langkah-langkah berikut menentukan cara melakukan tes TDD,

  1. Tambahkan tes.
  2. Jalankan semua pengujian dan lihat apakah ada pengujian baru yang gagal.
  3. Tulis beberapa kode.
  4. Jalankan tes dan kode Refactor.
  5. Ulang.

Siklus TDD mendefinisikan

  1. Tulis tes
  2. Jalankan.
  3. Ubah kode untuk memperbaikinya yaitu Refactor.
  4. Ulangi proses.

Beberapa klarifikasi tentang TDD:

  • TDD bukanlah tentang "Pengujian" atau tentang "Desain".
  • TDD tidak berarti "menulis beberapa pengujian, lalu membangun sistem yang lolos pengujian.
  • TDD tidak berarti "melakukan banyak Pengujian."

TDD Vs. Pengujian Tradisional

Pendekatan TDD pada dasarnya adalah teknik spesifikasi. Ini memastikan bahwa kode sumber Anda diuji secara menyeluruh pada tingkat konfirmasi.

  • Dengan pengujian tradisional, pengujian yang berhasil menemukan satu atau lebih cacat. Ini sama dengan TDD. Ketika tes gagal, Anda telah membuat kemajuan karena Anda tahu bahwa Anda perlu menyelesaikan masalah.
  • TDD memastikan bahwa sistem Anda benar-benar memenuhi persyaratan yang ditentukan untuknya. Ini membantu membangun kepercayaan diri Anda tentang sistem Anda.
  • Dalam TDD lebih banyak fokus pada kode produksi yang memverifikasi apakah pengujian akan bekerja dengan baik. Dalam pengujian tradisional, lebih banyak fokus pada desain kasus uji. Apakah pengujian akan menunjukkan pelaksanaan aplikasi yang benar / tidak tepat untuk memenuhi persyaratan.
  • Di TDD, Anda mencapai tes cakupan 100%. Setiap baris kode diuji, tidak seperti pengujian tradisional.
  • Kombinasi pengujian tradisional dan TDD mengarah pada pentingnya pengujian sistem daripada kesempurnaan sistem.
  • Dalam Agile Modeling (AM), Anda harus "menguji dengan tujuan". Anda harus tahu mengapa Anda menguji sesuatu dan tingkat apa yang perlu diuji.

Apa penerimaan TDD dan TDD Pengembang

Ada dua tingkat TDD

  1. Penerimaan TDD (ATDD): Dengan ATDD Anda menulis tes penerimaan tunggal. Pengujian ini memenuhi persyaratan spesifikasi atau memenuhi perilaku sistem. Setelah itu tulis kode produksi / fungsionalitas secukupnya untuk memenuhi uji penerimaan itu. Tes penerimaan berfokus pada perilaku sistem secara keseluruhan. ATDD juga dikenal sebagai Behavioral Driven Development (BDD).
  2. TDD Pengembang: Dengan TDD Pengembang Anda menulis tes pengembang tunggal yaitu tes unit dan kemudian kode produksi yang cukup untuk memenuhi tes itu. Pengujian unit berfokus pada setiap fungsionalitas kecil sistem. Pengembang TDD secara sederhana disebut sebagai TDD.

    Tujuan utama ATDD dan TDD adalah untuk menentukan persyaratan rinci yang dapat dieksekusi untuk solusi Anda pada basis tepat waktu (JIT). JIT berarti mengambil hanya persyaratan tersebut dalam pertimbangan yang dibutuhkan dalam sistem. Jadi tingkatkan efisiensi.

Penskalaan TDD melalui Agile Model Driven Development (AMDD)

TDD sangat bagus dalam spesifikasi dan validasi yang terperinci. Gagal memikirkan masalah yang lebih besar seperti desain keseluruhan, penggunaan sistem, atau UI. AMDD membahas masalah skala Agile yang tidak dimiliki TDD.

Jadi AMDD digunakan untuk masalah yang lebih besar.

Siklus hidup AMDD.

Dalam Model-driven Development (MDD), model ekstensif dibuat sebelum kode sumber ditulis. Yang mana pada gilirannya memiliki pendekatan yang gesit?

Pada gambar di atas, setiap kotak merepresentasikan aktivitas pembangunan.

Membayangkan adalah salah satu proses TDD untuk memprediksi / membayangkan tes yang akan dilakukan selama minggu pertama proyek. Tujuan utama dari membayangkan adalah untuk mengidentifikasi ruang lingkup sistem dan arsitektur sistem. Persyaratan tingkat tinggi dan pemodelan arsitektur dilakukan untuk membayangkan yang berhasil.

Ini adalah proses di mana tidak dilakukan spesifikasi rinci perangkat lunak / sistem tetapi mengeksplorasi persyaratan perangkat lunak / sistem yang menentukan strategi keseluruhan proyek.

  1. Iterasi 0: Membayangkan

Ada dua sub-aktif utama.

  1. Membayangkan persyaratan awal.

    Mungkin diperlukan beberapa hari untuk mengidentifikasi persyaratan tingkat tinggi dan cakupan sistem. Fokus utamanya adalah untuk mengeksplorasi model penggunaan, model domain awal, dan model antarmuka pengguna (UI).

  2. Visi Arsitektur Awal.

    Ini juga membutuhkan beberapa hari untuk mengidentifikasi arsitektur sistem. Ini memungkinkan pengaturan arahan teknis untuk proyek tersebut. Fokus utamanya adalah untuk mengeksplorasi diagram teknologi, aliran User Interface (UI), model domain, dan kasus perubahan.

  1. Pemodelan iterasi:

    Di sini tim harus merencanakan pekerjaan yang akan dilakukan untuk setiap iterasi.

  • Proses agile digunakan untuk setiap iterasi, yaitu pada setiap iterasi, item pekerjaan baru akan ditambahkan dengan prioritas.
  • Pekerjaan dengan prioritas lebih tinggi pertama akan dipertimbangkan. Item pekerjaan yang ditambahkan dapat diprioritaskan ulang atau dihapus dari tumpukan item kapan saja.
  • Tim membahas bagaimana mereka akan menerapkan setiap persyaratan. Pemodelan digunakan untuk tujuan ini.
  • Analisis dan perancangan pemodelan dilakukan untuk setiap kebutuhan yang akan diimplementasikan untuk iterasi tersebut.
  1. Model penyerbuan:

    Ini juga dikenal sebagai Just in time Modeling.

  • Di sini sesi pemodelan melibatkan tim yang terdiri dari 2/3 anggota yang membahas masalah di atas kertas atau papan tulis.
  • Seorang anggota tim akan meminta yang lain untuk menjadi model bersama mereka. Sesi pemodelan ini akan memakan waktu sekitar 5 hingga 10 menit. Di mana anggota tim berkumpul untuk berbagi papan tulis / kertas.
  • Mereka mengeksplorasi masalah sampai mereka tidak menemukan penyebab utama masalah tersebut. Tepat pada waktunya, jika salah satu anggota tim mengidentifikasi masalah yang ingin dia selesaikan, maka dia akan segera membantu anggota tim lainnya.
  • Anggota kelompok lainnya kemudian mengeksplorasi masalah tersebut dan kemudian setiap orang melanjutkan seperti sebelumnya. Ini juga disebut sebagai pemodelan stand-up atau sesi QA pelanggan.
  1. Test Driven Development (TDD).
  • Ini mempromosikan pengujian konfirmasi kode aplikasi Anda dan spesifikasi rinci.
  • Baik tes penerimaan (persyaratan rinci) dan tes pengembang (uji unit) adalah input untuk TDD.
  • TDD membuat kode lebih sederhana dan jelas. Ini memungkinkan pengembang untuk menyimpan lebih sedikit dokumentasi.
  1. Ulasan.
  • Ini opsional. Ini termasuk inspeksi kode dan ulasan model.
  • Ini dapat dilakukan untuk setiap iterasi atau untuk keseluruhan proyek.
  • Ini adalah pilihan yang baik untuk memberikan umpan balik untuk proyek tersebut.

Test Driven Development (TDD) Vs. Agile Model Driven Development (AMDD)

TDD AMDD
  • TDD memperpendek loop umpan balik pemrograman
  • AMDD memperpendek putaran umpan balik pemodelan.
  • TDD adalah spesifikasi rinci
  • AMDD berfungsi untuk masalah yang lebih besar
  • TDD mempromosikan pengembangan kode berkualitas tinggi
  • AMDD mempromosikan komunikasi berkualitas tinggi dengan pemangku kepentingan dan pengembang.
  • TDD berbicara kepada programmer
  • AMDD berbicara dengan analis bisnis, pemangku kepentingan, dan profesional data.
  • TDD berorientasi non-visual
  • AMDD berorientasi visual
  • TDD memiliki ruang lingkup terbatas untuk pekerjaan perangkat lunak
  • AMDD memiliki cakupan yang luas termasuk pemangku kepentingan. Ini melibatkan bekerja menuju pemahaman bersama
  • Keduanya mendukung perkembangan evolusioner
 --------------------------------------------

Contoh TDD

Di sini, di contoh ini, kami akan menentukan kata sandi kelas. Untuk kelas ini, kami akan mencoba memenuhi ketentuan berikut.

Syarat penerimaan Kata Sandi:

  • Kata sandi harus antara 5 hingga 10 karakter.

Pertama, kami menulis kode yang memenuhi semua persyaratan di atas.

Skenario 1 : Untuk menjalankan pengujian, kami membuat kelas PasswordValidator ();

Kami akan menjalankan di atas kelas TestPassword ();

Output DILAKUKAN seperti yang ditunjukkan di bawah ini;

Keluaran :

Skenario 2 : Di sini kita dapat melihat dalam metode TestPasswordLength () tidak perlu membuat instance kelas PasswordValidator. Instance berarti membuat objek kelas untuk merujuk anggota (variabel / metode) kelas itu.

Kami akan menghapus kelas PasswordValidator pv = new PasswordValidator () dari kode. Kita bisa memanggil metode isValid () secara langsung dengan PasswordValidator. IsValid ("Abc123") . (Lihat gambar di bawah)

Jadi kami Refactor (ubah kode) seperti di bawah ini:

Skenario 3 : Setelah refactoring, output menunjukkan status gagal (lihat gambar di bawah) ini karena kami telah menghapus instance. Jadi tidak ada referensi ke metode non -static isValid ().

Jadi kita perlu mengubah metode ini dengan menambahkan kata "statis" sebelum Boolean sebagai public static boolean isValid (String password). Refactoring Class PasswordValidator () untuk menghapus kesalahan di atas agar lulus ujian.

Keluaran:

Setelah melakukan perubahan pada class PassValidator () jika kita menjalankan test maka outputnya akan PASSED seperti gambar di bawah ini.

Keuntungan TDD

  • Pemberitahuan bug awal.

    Pengembang menguji kode mereka tetapi dalam dunia database, ini sering kali terdiri dari tes manual atau skrip satu kali. Dengan menggunakan TDD, Anda membangun, seiring waktu, serangkaian pengujian otomatis yang dapat Anda dan pengembang lain lakukan sesuka hati.

  • Kode yang dirancang lebih baik, lebih bersih, dan lebih dapat diperluas.
    • Ini membantu untuk memahami bagaimana kode akan digunakan dan bagaimana berinteraksi dengan modul lain.
    • Ini menghasilkan keputusan desain yang lebih baik dan kode yang lebih mudah dirawat.
    • TDD memungkinkan penulisan kode yang lebih kecil yang memiliki tanggung jawab tunggal daripada prosedur monolitik dengan banyak tanggung jawab. Ini membuat kode lebih sederhana untuk dipahami.
    • TDD juga memaksa untuk hanya menulis kode produksi untuk lulus tes berdasarkan kebutuhan pengguna.
  • Keyakinan untuk Refactor
    • Jika Anda memfaktor ulang kode, ada kemungkinan kode terputus. Jadi dengan memiliki serangkaian pengujian otomatis, Anda dapat memperbaiki jeda tersebut sebelum rilis. Peringatan yang tepat akan diberikan jika ditemukan kerusakan saat tes otomatis digunakan.
    • Menggunakan TDD, akan menghasilkan kode yang lebih cepat dan lebih dapat diperluas dengan lebih sedikit bug yang dapat diperbarui dengan risiko minimal.
  • Bagus untuk kerja tim

    Jika tidak ada anggota tim, anggota tim lain dapat dengan mudah mengambil dan mengerjakan kode. Ini juga membantu berbagi pengetahuan, sehingga membuat tim lebih efektif secara keseluruhan.

  • Bagus untuk Pengembang

    Meskipun pengembang harus menghabiskan lebih banyak waktu untuk menulis kasus uji TDD, dibutuhkan lebih sedikit waktu untuk men-debug dan mengembangkan fitur baru. Anda akan menulis kode yang lebih bersih dan tidak rumit.

Ringkasan:

  • TDD adalah singkatan dari Test-driven development. Ini adalah proses memodifikasi kode untuk lulus tes yang dirancang sebelumnya.
  • Ini lebih menekankan pada kode produksi daripada desain kasus uji.
  • Pengembangan yang digerakkan oleh pengujian adalah proses memodifikasi kode untuk lulus pengujian yang dirancang sebelumnya.
  • Dalam Rekayasa Perangkat Lunak, terkadang disebut sebagai "Uji Pengembangan Pertama."
  • TDD termasuk refactoring kode yaitu mengubah / menambahkan sejumlah kode ke kode yang ada tanpa mempengaruhi perilaku kode.
  • TDD saat digunakan, kodenya menjadi lebih jelas dan mudah dimengerti.

Artikel ini dikontribusikan oleh Kanchan Kulkarni