Apa itu Test Driven Development, pendekatan dan keunggulannya

Test Driven Development (TDD) adalah pendekatan pengembangan perangkat lunak di mana kasus uji dikembangkan untuk menentukan dan memvalidasi apa yang akan dilakukan oleh kode.

Hampir semua kasus pengujian untuk setiap fitur dibuat dan diuji sebelum perangkat lunak dirilis, dan jika pengujian gagal, kode baru ditulis (atau ditulis ulang atau ditambal) untuk lulus pengujian dan membuat kode menjadi sederhana dan bebas bug.

Test Driven Development (TDD) dimulai dengan merancang dan mengembangkan pengujian untuk setiap fitur kecil dalam aplikasi. Kerangka kerja TDD menginstruksikan pengembang untuk menulis kode baru hanya jika pengujian otomatis gagal. Pendekatan ini menghindari duplikasi kode. Modul TDD yang lengkap adalah pengembangan yang digerakkan oleh pengujian.

Test Driven Development (TDD) berasal sebagai bagian dari paradigma desain perangkat lunak yang lebih besar yang dikenal sebagai Extreme Programming (XP), yang merupakan bagian dari metodologi pengembangan perangkat lunak Agile.

Konsep sederhana TDD adalah menulis dan memperbaiki pengujian yang gagal sebelum menulis kode baru (sebelum pengembangan). Ini membantu menghindari duplikasi kode karena kami menulis sejumlah kecil kode sekaligus untuk lulus ujian. (Pengujian tidak lebih dari kondisi persyaratan yang harus kita uji untuk memuaskannya).

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

Fase pendekatan TDD

Sebelum kode baru ditulis, pemrogram harus terlebih dahulu membuat unit test yang gagal. Kemudian, pemrogram – atau pasangan, atau massa – membuat kode yang cukup untuk memenuhi kebutuhan itu. Setelah tes lulus, pemrogram dapat memperbaiki proyek, melakukan perbaikan tanpa mengubah perilaku.

Sementara TDD berfokus pada interaksi pemrogram tingkat unit, ada metode populer lainnya, seperti acceptance test-driven development (ATDD) atau behavior-driven development (BDD), yang berfokus pada pengujian yang dapat dipahami oleh pelanggan.

Metode ini melibatkan pembuatan contoh dunia nyata sebagai pengujian kolaboratif antara staf teknik dan pelanggan sebelum pengkodean, dan kemudian menjalankan pengujian setelah pengkodean untuk menunjukkan bahwa kode tersebut diterapkan. Memiliki tes yang diketahui sebelumnya meningkatkan kualitas pertama kali. ATDD dan BDD membutuhkan pengembang, penguji, dan pihak bisnis untuk bekerja sama membayangkan dan mendiskusikan perangkat lunak dan implikasinya sebelum kode dibuat.

Keuntungan TDD

Pengembangan berbasis pengujian dapat menghasilkan aplikasi berkualitas tinggi dalam waktu yang lebih singkat dibandingkan dengan metode lama. Implementasi TDD yang sukses membutuhkan pengembang dan penguji untuk secara akurat mengantisipasi bagaimana aplikasi dan fungsinya akan digunakan di dunia nyata.

TDD membangun rangkaian uji regresi sebagai efek samping yang dapat meminimalkan pengujian manual manusia, menemukan masalah lebih awal, menghasilkan solusi yang lebih cepat. Sifat metodis TDD memastikan cakupan dan kualitas pertama kali yang jauh lebih tinggi daripada siklus kode bertahap klasik > uji > perbaiki > uji ulang. Karena pengujian dilakukan di awal siklus desain, waktu dan uang yang dihabiskan untuk debugging nanti diminimalkan.

Keuntungan yang diharapkan:

• pengurangan yang signifikan dalam tingkat cacat, dengan biaya peningkatan moderat dalam upaya pengembangan awal
• biaya overhead lebih dari diimbangi oleh pengurangan upaya pada tahap akhir proyek
• TDD mengarah ke kualitas desain yang lebih baik dalam kode dan, secara lebih umum, tingkat kualitas "internal" atau teknis yang lebih tinggi, misalnya dengan meningkatkan metrik kohesi dan kopling

Kekurangan TDD

TDD membutuhkan keterampilan yang cukup untuk menjadi sukses, terutama di level unit. Banyak sistem lawas tidak dibangun dengan mempertimbangkan pengujian unit, sehingga tidak mungkin untuk mengisolasi komponen untuk pengujian.

Selain itu, banyak pemrogram tidak memiliki keterampilan untuk mengisolasi dan membuat kode yang bersih. Semua anggota tim harus membuat dan memelihara unit test atau mereka akan segera menjadi usang. Dan organisasi yang melihat TDD harus menginvestasikan waktu, sedikit melambat sekarang untuk melaju lebih cepat nanti.

Akhirnya, seperti halnya metode apa pun, hasil akhir TDD hanya sebaik tes yang digunakan, seberapa akuratnya dilakukan, dan sejauh mana mereka meniru kondisi yang dihadapi oleh pengguna produk akhir.

Kesalahan Umum:

• sering lupa menjalankan tes
• menulis terlalu banyak tes sekaligus
• tulis tes yang terlalu besar atau kotor
• menulis tes yang terlalu sepele, seperti menghilangkan pernyataan
• tes tulis untuk kode sepele
• adopsi parsial: hanya beberapa pengembang dalam kelompok kerja yang menggunakan TDD
• perawatan rangkaian pengujian yang buruk, paling sering mengarah ke rangkaian pengujian dengan waktu pengoperasian yang sangat lama
• test suite ditinggalkan (yaitu jarang atau tidak pernah dijalankan) – terkadang karena pemeliharaan yang buruk, terkadang karena pergantian tim

filosofi TDD

TDD memungkinkan programmer untuk mengambil langkah kecil saat menulis perangkat lunak. Pengujian ditulis sebelum menguji fungsionalitas dan memastikan bahwa aplikasi cocok untuk pengujian. Pengujian pada sejumlah kecil kode dilakukan untuk mengetahui error yang terjadi pada kode yang diuji. Kemudian fungsionalitas diimplementasikan. Ini disebut sebagai "refactor merah hijau" di mana merah berarti kegagalan dan hijau menunjukkan lulus. Langkah-langkah ini kemudian diulangi. Tujuan pertama seorang programmer adalah fokus pada tugas yang ada dan mengatasinya.

Tahapan berbeda yang terlibat dalam siklus pengembangan berbasis tes adalah:

• Tambahkan Pengujian: Setiap fitur baru di TDD dimulai dengan pengujian yang harus gagal karena dilakukan sebelum fitur apa pun diterapkan. Prasyarat untuk menulis tes sebelum mengimplementasikan fitur adalah pemahaman yang jelas tentang persyaratan oleh pengembang. Ini dicapai melalui cerita pengguna dan kasus penggunaan. Jadi pengembang memahami persyaratan sebelum menulis kode program.
• Jalankan semua pengujian dan periksa apakah kode baru gagal: ini memastikan bahwa rangkaian pengujian bekerja dengan benar dan pengujian baru tidak gagal tanpa kode baru. Langkah ini juga memverifikasi pengujian dan menghilangkan kemungkinan bahwa pengujian baru akan selalu lulus.
• Tulis Kode: Langkah selanjutnya adalah menulis kode yang menyelesaikan tes. Kode baru tidak sempurna tetapi kemudian dimodifikasi sesuai kebutuhan. Ini dirancang hanya untuk pengujian dan tidak mengemas fitur lain.
• Jalankan Tes Otomatis: Jika setiap test case yang dihasilkan lulus tes dengan mudah, itu berarti kode tersebut memenuhi semua spesifikasi yang diperlukan. Kemudian fase akhir dari siklus dapat dimulai.
• Kode refactoring: Ini mirip dengan menghapus duplikasi. Refactoring tidak merusak fungsionalitas yang ada dan membantu menghilangkan duplikasi antara kode produksi dan pengujian. Kode sekarang dibersihkan sesuai kebutuhan.
• Ulangi: Siklus berulang seperti pada kasus sebelumnya dengan tes baru. Persyaratan penting adalah ukuran langkah kecil, dengan sekitar 1-10 perubahan antara setiap uji coba. Jika kode baru gagal dalam pengujian baru, pemrogram harus melakukan lebih banyak debug. Integrasi berkelanjutan menyediakan pos pemeriksaan yang dapat dibalik.

Ercole Palmeri