Apa itu Pengembangan Berbasis Tes (TDD)? Contoh

Oleh: Thomas Hamilton Thomas Hamilton
Hours Updated

Apa itu Pengembangan Berbasis Tes (TDD)?

Pengembangan Berbasis Uji (TDD) adalah pendekatan pengembangan perangkat lunak di mana kasus uji dikembangkan untuk menentukan dan memvalidasi apa yang akan dilakukan kode. Sederhananya, kasus pengujian untuk setiap fungsionalitas dibuat dan diuji terlebih dahulu dan jika pengujian gagal maka kode baru ditulis agar dapat lulus pengujian dan membuat kode menjadi sederhana dan bebas bug.

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

Pengembangan Berbasis Tes

Konsep sederhana TDD adalah menulis dan memperbaiki pengujian yang gagal sebelum menulis kode baru (sebelum pengembangan). Hal ini membantu menghindari duplikasi kode saat kita menulis sejumlah kecil kode sekaligus agar dapat lulus pengujian. (Tes tidak lain adalah kondisi persyaratan yang perlu kita uji untuk memenuhinya).

Pengembangan berbasis pengujian adalah proses mengembangkan dan menjalankan pengujian otomatis sebelum pengembangan aplikasi sebenarnya. Oleh karena itu, TDD terkadang juga disebut sebagai Uji Perkembangan Pertama.

Cara melakukan Tes TDD

Langkah-langkah berikut menentukan cara melakukan pengujian 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. Ulangi.
Lakukan Tes TDD
Lima Langkah Pengembangan Berbasis Tes

Siklus TDD mendefinisikan

  1. Tulis tes
  2. Jalankan.
  3. Ubah kodenya agar benar yaitu Refactor.
  4. Ulangi proses.

Beberapa klarifikasi tentang TDD:

  • Pendekatan TDD bukan tentang “Pengujian” atau tentang “Desain”.
  • TDD tidak berarti “menulis beberapa pengujian, lalu membangun sistem yang lulus pengujian tersebut.
  • TDD tidak berarti “melakukan banyak Pengujian.”

TDD Vs. Pengujian Tradisional

Di bawah ini adalah perbedaan utama antara pengembangan yang didorong oleh pengujian dan 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. Itu sama dengan TDD. Ketika tes gagal, Anda telah membuat kemajuan karena Anda tahu bahwa Anda perlu menyelesaikan masalah tersebut.
  • TDD memastikan bahwa sistem Anda benar-benar memenuhi persyaratan yang ditentukan untuknya. Ini membantu membangun kepercayaan diri Anda tentang sistem Anda.
  • Di TDD, fokusnya lebih pada kode produksi yang memverifikasi apakah pengujian akan berfungsi dengan baik. Dalam pengujian tradisional, lebih fokus pada desain kasus uji. Apakah pengujian akan menunjukkan eksekusi aplikasi yang tepat/tidak tepat untuk memenuhi persyaratan.
  • Di TDD, Anda mencapai uji cakupan 100%. Setiap baris kode diuji, tidak seperti pengujian tradisional.
  • Kombinasi pengujian tradisional dan TDD mengarah pada pentingnya pengujian sistem daripada kesempurnaan sistem.
  • In Pemodelan Agile (AM), Anda harus “menguji dengan suatu tujuan”. Anda harus tahu mengapa Anda menguji sesuatu dan pada tingkat apa hal itu perlu diuji.

ARTIKEL TERKAIT

Apa itu TDD penerimaan 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/fungsi secukupnya untuk memenuhi uji penerimaan tersebut. Tes penerimaan berfokus pada perilaku sistem secara keseluruhan. ATDD juga dikenal sebagai Pengembangan Berbasis Perilaku (BDD).
  2. TDD Pengembang: Dengan Pengembang TDD Anda menulis pengujian pengembang tunggal yaitu pengujian unit dan kemudian kode produksi yang cukup untuk memenuhi pengujian tersebut. Pengujian unit berfokus pada setiap fungsionalitas kecil dari sistem. Pengembang TDD hanya disebut sebagai TDD.Tujuan utama ATDD dan TDD adalah untuk menentukan persyaratan terperinci dan dapat dieksekusi untuk solusi Anda berdasarkan just in time (JIT). JIT berarti hanya mempertimbangkan persyaratan yang diperlukan dalam sistem. Jadi tingkatkan efisiensi.

TDD Penerimaan dan TDD Pengembang

Menskalakan TDD melalui Agile Model Driven Development (AMDD)

TDD sangat bagus dalam spesifikasi dan validasi detail. Ia gagal memikirkan masalah yang lebih besar seperti keseluruhan desain, penggunaan sistem, atau UI. AMDD mengatasi masalah penskalaan Agile yang tidak dimiliki TDD.

Jadi AMDD digunakan untuk masalah yang lebih besar.

Siklus hidup AMDD

Siklus Hidup AMDD

Dalam Pengembangan Berbasis Model (MDD), model ekstensif dibuat sebelum kode sumber ditulis. Manakah yang memiliki pendekatan tangkas?

Pada gambar di atas, setiap kotak mewakili suatu aktivitas pengembangan.

Envisioning merupakan salah satu proses TDD berupa pengujian prediksi/imajinasi yang akan dilakukan selama minggu pertama proyek. Tujuan utama envisioning adalah untuk mengidentifikasi cakupan sistem dan arsitektur sistem. Pemodelan persyaratan dan arsitektur tingkat tinggi dilakukan untuk envisioning yang berhasil.

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

Iterasi 0: Membayangkan

Ada dua sub-aktif utama.

  1. Perencanaan persyaratan awal.Mungkin diperlukan waktu beberapa hari untuk mengidentifikasi persyaratan tingkat tinggi dan cakupan sistem. Fokus utamanya adalah mengeksplorasi model penggunaan, model domain awal, dan model antarmuka pengguna (UI).
  2. Awal Archivisi tektural. Proses ini juga memerlukan waktu beberapa hari untuk mengidentifikasi arsitektur sistem. Proses ini memungkinkan pengaturan arahan teknis untuk proyek tersebut. Fokus utamanya adalah untuk mengeksplorasi diagram teknologi, alur Antarmuka Pengguna (UI), model domain, dan kasus Perubahan.

Pemodelan iterasi

Disini 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 mendiskusikan bagaimana mereka akan menerapkan setiap persyaratan. Pemodelan digunakan untuk tujuan ini.
  • Analisis dan desain pemodelan dilakukan untuk setiap persyaratan yang akan diimplementasikan untuk iterasi tersebut.

Model menyerbu

Ini juga dikenal sebagai Pemodelan Tepat Waktu.

  • Di sini sesi pemodelan melibatkan tim yang terdiri dari 2/3 anggota yang mendiskusikan masalah di atas kertas atau papan tulis.
  • Salah satu anggota tim akan meminta anggota tim lainnya untuk menjadi model bersama mereka. Sesi pemodelan ini akan memakan waktu kurang lebih 5 hingga 10 menit. Dimana anggota tim berkumpul untuk berbagi papan tulis/kertas.
  • Mereka mendalami permasalahan hingga tidak menemukan penyebab utama permasalahan tersebut. Tepat pada waktunya, jika salah satu anggota tim mengidentifikasi masalah yang ingin dia selesaikan maka dia akan segera meminta bantuan anggota tim lainnya.
  • Anggota kelompok yang lain kemudian mengeksplorasi permasalahan tersebut dan kemudian semua orang melanjutkan seperti sebelumnya. Ini juga disebut sebagai stand-up modeling atau sesi QA pelanggan.

Pengembangan Berbasis Uji (TDD)

  • Ini mempromosikan pengujian konfirmasi kode aplikasi dan spesifikasi terperinci Anda.
  • Uji penerimaan (persyaratan terperinci) dan uji pengembang (uji unit) merupakan masukan untuk TDD.
  • TDD membuat kode lebih sederhana dan jelas. Hal ini memungkinkan pengembang untuk menyimpan lebih sedikit dokumentasi.

Review

  • Ini opsional. Ini mencakup inspeksi kode dan tinjauan model.
  • Hal ini dapat dilakukan untuk setiap iterasi atau untuk keseluruhan proyek.
  • Ini adalah pilihan yang baik untuk memberikan umpan balik terhadap proyek tersebut.

Pengembangan Berbasis Uji (TDD) Vs. Pengembangan Berbasis Model Agile (AMDD)

TDD AMDD
TDD memperpendek putaran 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 tidak berorientasi visual AMDD berorientasi visual
TDD memiliki cakupan terbatas pada pekerjaan perangkat lunak AMDD memiliki cakupan yang luas termasuk pemangku kepentingan. Ini melibatkan upaya menuju pemahaman bersama
Keduanya mendukung perkembangan evolusioner ---------------

Kerangka TDD

Berikut adalah daftar kerangka kerja pengembangan berbasis pengujian (TDD) terbaik

  1. Junit
  2. TestNG
  3. csUnit dan NUnit
  4. Spesifikasi

Sekarang, mari pelajari Test Driven Development dengan memberi contoh.

Contoh TDD

Di sini, dalam contoh Pengembangan Berbasis Uji ini, kami akan mendefinisikan kata sandi kelas. Untuk kelas ini, kami akan mencoba memenuhi ketentuan berikut.

Syarat untuk penerimaan Kata Sandi:

  • Kata sandi harus antara 5 hingga 10 karakter.

Pertama dalam contoh TDD ini, kita menulis kode yang memenuhi semua persyaratan di atas.

Contoh TDD

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

Contoh TDD

Kami akan menjalankan kelas TestPassword() di atas;

Outputnya LULUS seperti gambar di bawah ini;

Keluaran:

Contoh TDD

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

Contoh TDD

Kami akan menghapus kelas PasswordValidator pv = new PasswordValidator () dari kode. Kita bisa menghubungi adalah benar () metode langsung oleh Validator Kata Sandi. ApakahValid (“Abc123”). (Lihat gambar di bawah)

Jadi kita Refactor (mengubah kode) seperti di bawah ini:

Contoh TDD

Skenario 3: Setelah melakukan refactoring, output menunjukkan status gagal (lihat gambar di bawah) ini karena kita telah menghapus instance. Jadi tidak ada referensi ke metode non-statis adalah benar ().

Contoh TDD

Jadi kita perlu mengubah metode ini dengan menambahkan kata “statis” sebelum Boolean sebagai boolean statis publik isValid (Kata sandi string). Memfaktorkan Ulang Kelas PasswordValidator () untuk menghapus kesalahan di atas agar lulus ujian.

Contoh TDD

Keluaran:

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

Contoh TDD

Keuntungan dari TDD

Berikut ini adalah keuntungan utama dari Test Driven Development dalam Rekayasa Perangkat Lunak:

Pemberitahuan bug awal.

  • Pengembang menguji kode mereka tetapi dalam dunia basis data, hal ini sering kali terdiri dari pengujian manual atau skrip satu kali. Dengan menggunakan TDD, Anda membangun, seiring berjalannya waktu, serangkaian pengujian otomatis yang dapat Anda dan pengembang lain jalankan kembali sesuai keinginan.

Kode yang dirancang lebih baik, lebih bersih, dan lebih dapat diperluas.

  • Ini membantu untuk memahami bagaimana kode akan digunakan dan bagaimana kode tersebut berinteraksi dengan modul lain.
  • Ini menghasilkan keputusan desain yang lebih baik dan kode yang lebih mudah dipelihara.
  • TDD memungkinkan penulisan kode yang lebih kecil yang memiliki tanggung jawab tunggal daripada prosedur monolitik dengan banyak tanggung jawab. Hal ini membuat kode lebih mudah untuk dipahami.
  • TDD juga memaksa untuk hanya menulis kode produksi agar lulus pengujian berdasarkan kebutuhan pengguna.

Keyakinan untuk Refactor

  • Jika Anda memfaktorkan ulang kode, ada kemungkinan kerusakan pada kode. Jadi, dengan serangkaian pengujian otomatis, Anda dapat memperbaiki kerusakan tersebut sebelum rilis. Peringatan yang tepat akan diberikan jika ditemukan kerusakan saat pengujian 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 lainnya dapat dengan mudah mengambil dan mengerjakan kode tersebut. Hal ini juga membantu berbagi pengetahuan, sehingga membuat tim lebih efektif secara keseluruhan.

Bagus untuk Pengembang

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

Kesimpulan

  • TDD adalah singkatan dari Pengembangan yang didorong oleh pengujian.
  • Arti TDD: Ini adalah proses memodifikasi kode agar lulus tes yang dirancang sebelumnya.
  • Ini lebih menekankan pada kode produksi daripada desain kasus uji.
  • Pengembangan berbasis pengujian adalah proses memodifikasi kode agar lulus pengujian yang dirancang sebelumnya.
  • In Rekayasa Perangkat Lunak, Kadang-kadang dikenal sebagai “Uji Perkembangan Pertama.”
  • Pengujian TDD mencakup pemfaktoran ulang kode, yaitu mengubah/menambahkan sejumlah kode ke kode yang sudah ada tanpa mempengaruhi perilaku kode.
  • Pemrograman TDD ketika digunakan, kodenya menjadi lebih jelas dan mudah dipahami.

Anda mungkin ingin: