{"id":551,"date":"2022-01-26T01:34:13","date_gmt":"2022-01-26T01:34:13","guid":{"rendered":"https:\/\/www.cybermedian.com\/id\/?p=551"},"modified":"2025-02-17T11:51:33","modified_gmt":"2025-02-17T03:51:33","slug":"test-drive-development-approach-for-agile-software-development","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/id\/test-drive-development-approach-for-agile-software-development\/","title":{"rendered":"Pendekatan Pengembangan Berbasis Uji untuk Pengembangan Perangkat Lunak Agile"},"content":{"rendered":"
\n
\n
\n

Sekarang, orang sering membicarakan tentang pengembangan agile.<\/p>\n

Apa itu Pengembangan Agile?<\/h4>\n

Pengembangan agile<\/a> adalah kemampuan pengembangan perangkat lunak yang merespons kebutuhan yang berubah dengan cepat. Nama, konsep, proses, dan terminologi spesifik mereka bervariasi. Dibandingkan dengan \u201cnon-agile<\/a>,\u201d mereka menekankan kolaborasi erat antara tim programmer dan ahli bisnis, komunikasi tatap muka (dianggap lebih efektif daripada dokumentasi tertulis), dan seringkali mengeluarkan rilis perangkat lunak baru, kecil dan tim yang mengorganisir diri sendiri<\/a> untuk penulisan fitur kecil dan berharga, serta pendekatan organisasi tim yang beradaptasi dengan kebutuhan yang berubah, dengan fokus yang lebih besar pada peran orang dalam pengembangan perangkat lunak.<\/p>\n

Namun, ada beberapa versi serupa dari metode pengembangan agile TDD, seperti TDD: BDD, DDD, dan ATDD. Izinkan saya memperkenalkan metode ini secara singkat sebelum memperkenalkan TDD secara rinci:<\/p>\n

TDD: Pengembangan Berbasis Uji<\/strong><\/p>\n

Pengembangan Berbasis Uji<\/a> (TDD) adalah proses pengembangan perangkat lunak, yang bergantung pada mengubah persyaratan perangkat lunak menjadi kasus uji sebelum perangkat lunak sepenuhnya dikembangkan, dan melacak semua pengembangan perangkat lunak dengan menguji perangkat lunak secara berulang untuk semua kasus uji. Ini adalah kebalikan dari mengembangkan perangkat lunak terlebih dahulu dan kemudian membuat kasus uji. Beberapa model populer mendukung TDD dengan sangat baik, seperti MVC dan MVP<\/a>.<\/p>\n

<\/figure>\n

BDD: Pengembangan Berbasis Perilaku (Behavior Driven Development)<\/strong><\/p>\n

Pengembangan berbasis perilaku (BDD) juga merupakan proses pengembangan perangkat lunak agile. Ini mendorong kolaborasi antara pengembang, penguji jaminan kualitas, dan perwakilan pelanggan dalam proyek perangkat lunak. Ini mendorong tim untuk menggunakan percakapan dan contoh konkret untuk memformalkan pemahaman bersama tentang bagaimana aplikasi seharusnya bekerja. Ini berasal dari pengembangan berbasis uji (TDD).<\/p>\n

<\/figure>\n

ATDD: Pengembangan Berbasis Uji Penerimaan<\/strong><\/p>\n

Untuk mempromosikan realisasi kode fungsional melalui kasus uji unit, tim perlu mendefinisikan standar kualitas yang diharapkan dan aturan penerimaan, serta mempromosikan praktik TDD pengembang dan kinerja penguji melalui rencana uji penerimaan yang jelas dan konsisten (termasuk serangkaian skenario uji). Bagi pengembang, ini menekankan bagaimana mengimplementasikan sistem dan bagaimana mengujinya.<\/p>\n

<\/figure>\n

DDD: Desain Berbasis Domain<\/strong><\/p>\n

DDD mengacu pada desain berbasis domain, yaitu pengembangan berbasis domain. DDD sebenarnya dibangun di atas fondasi ini karena fokus pada desain lapisan layanan, fokus pada implementasi bisnis, menggabungkan analitik dan desain, dan tidak lagi mempertahankannya dalam keadaan terpisah, untuk secara benar dan komprehensif mengimplementasikan kebutuhan pelanggan dan membangun model skalabilitas bisnis.<\/p>\n

<\/figure>\n

Rencana implementasi TDD<\/h3>\n
\n

Melalui pengujian untuk mempromosikan seluruh pengembangan, tetapi pengembangan berbasis uji bukan hanya pekerjaan uji sederhana, tetapi proses untuk mengkuantifikasi analisis persyaratan, desain, dan kontrol kualitas.<\/em><\/p>\n<\/blockquote>\n

Prinsip pengembangan<\/strong><\/p>\n

\n

Tulis kode uji terlebih dahulu, dan kemudian tulis kode untuk fungsi.<\/em><\/p>\n<\/blockquote>\n

    \n
  1. Tulis kode uji sesuai dengan dokumen persyaratan, bukan untuk merealisasikan fungsi;<\/li>\n
  2. Jangan ingin menyelesaikan semuanya sekaligus. Saat menguji blok fungsional besar, Anda harus terlebih dahulu membaginya menjadi blok fungsional yang lebih kecil untuk diuji;<\/li>\n
  3. Ingatlah untuk tidak menulis kode untuk menyelesaikan fungsi, gunakan kode yang paling sederhana untuk mengimplementasikan fungsi;<\/li>\n
  4. Jika persyaratan dapat diuji, tulis kode uji, dan tinggalkan yang tidak dapat diuji atau merasa bahwa mereka tidak perlu diuji;<\/li>\n
  5. Sebelum mengubah\/menambahkan kode fungsi apa pun, Anda harus terlebih dahulu memikirkan apakah Anda ingin mengubah\/menambahkan kasus uji;<\/li>\n
  6. Kode fungsi\/kode uji, struktur yang tidak masuk akal, kode duplikat, dll., refactor tepat waktu setelah pengujian berhasil.<\/li>\n<\/ol>\n

    Proses pengembangan TDD<\/strong><\/p>\n

      \n
    1. Analisis dan tentukan skenario uji target;<\/li>\n
    2. Tambahkan uji unit untuk memverifikasi input dan output dari skenario uji;<\/li>\n
    3. Jalankan pengujian dan dapatkan hasil pengujian yang gagal;<\/li>\n
    4. Tulis kode fungsi yang paling sederhana untuk lulus uji;<\/li>\n
    5. Jalankan pengujian lagi dan lihat bahwa pengujian berhasil;<\/li>\n
    6. Lakukan refactoring kode, termasuk kode fungsional dan kode uji unit;<\/li>\n
    7. Ulangi langkah-langkah di atas sampai pengembangan selesai.<\/li>\n<\/ol>\n

      Manfaat TDD<\/strong><\/p>\n

        \n
      1. Mengurangi beban pada pengembang<\/strong>. Melalui proses yang jelas, mari kita fokus pada satu titik pada satu waktu, dan beban berpikir menjadi lebih ringan.<\/li>\n
      2. Jaring perlindungan<\/strong>. Menyediakan pengujian unit yang lengkap memberikan jaring perlindungan untuk kode produk, memudahkan untuk memenuhi perubahan dalam persyaratan atau meningkatkan desain kode. Jadi jika persyaratan proyek Anda stabil, selesai sekaligus, dan tidak ada perubahan selanjutnya, manfaat TDD menjadi lebih sedikit.<\/li>\n
      3. Jelaskan persyaratan sebelumnya<\/strong>. Menulis uji terlebih dahulu dapat membantu kita memikirkan persyaratan dan menjelaskan rincian persyaratan sebelumnya, daripada menemukan persyaratan yang tidak jelas hanya di tengah kode.<\/li>\n
      4. Umpan balik cepat<\/strong>. Banyak orang mengatakan bahwa ketika TDD, volume kode saya meningkat, sehingga efisiensi pengembangan menurun. Namun, jika Anda tidak memiliki uji unit, Anda harus mengujinya secara manual, Anda menghabiskan banyak waktu untuk menyiapkan data, meluncurkan aplikasi, memodifikasi antarmuka, dan sebagainya, dan umpan balik menjadi lambat. Secara tepat, umpan balik cepat adalah manfaat dari pengujian unit.<\/li>\n<\/ol>\n<\/div>\n<\/div>\n<\/section>\n
        \n
        \n
        \n<\/div>\n
        \n
        \n

        Prinsip Agile & Scrum<\/h4>\n