## JEPIN
(Jurnal Edukasi dan Penelitian Informatika)
ISSN(e): 2548-9364 / ISSN(p) : 2460-0741
Vol. 9 No. 3 Desember 2023

## Dampak Test-Driven Development pada Kualitas Kode
Muhammad Iqbal Naufal Ilmi #1 , Aminudin #2 , Zamah Sari #3
# Program Studi Teknik Informatika, Universitas Muhammadiyah Malang Jl. Raya Tlogomas No.246 Malang,
1 iqbalmnaufal@webmail.umm.ac.id
2 aminudin2008@umm.ac.id
3 zamahsari@umm.ac.id
Abstrak—  Pengembang  perangkat  lunak  sekarang  dituntut untuk memiliki perangkat lunak yang baik. Salah satu faktor yang  membuat  perangkat  lunak  tersebut  baik  adalah  bebas dari  berbagai  macam  bug  dan  program  mudah  untuk dirawat.  Salah  satu  cara  untuk  mendapatkan  hal  tersebut adalah  menggunakan  Test-Driven  Development  (TDD).  TDD adalah  metode  dengan  menuliskan  pengujian  sebelum  kode program.  Dengan  TDD  diharapkan  memiliki  kualitas  kode yang baik dan bebas dari berbagai macam  bug. Karena hal tersebut,  pada  paper  ini  akan  diteliti  tentang  dampak  yang terjadi  ketika  menggunakan  TDD  dalam  nilai-nilai  seperti code  coverage,  halstead  volume  dan  maintainability  index. Hasilnya  didapatkan  bahwa  dengan  menggunakan  TDD dapat meningkatkan matriks pada indikator tersebut karena pengembang  memiliki  kesempatan  untuk  berfokus  pada penulisan  test  di  awal  sebagai  awal  siklus  dan  fokus  pada akhir  siklus.  Berdasarkan  perhitungan  yang  dilakukan, didapatkan hasil dengan penggunaan TDD dapat meningkatkan  nilai  code  coverage  sampai  lebih  dari  100%, cyclomatic  complexity  sebesar  15.78%,  halstead  volume sebesar  35%  dan  maintainability  index  sebesar  11%.  Hal tersebut  terjadi  karena  kode  lebih  banyak  yang  dijangkau oleh  pengujian  dan  setiap  siklus  diakhiri  dengan  refactor sehingga  program  akan  diperbaiki  setiap  siklus  sehingga kualitas kode menjadi lebih baik.
Kata  kunci — Test-Driven  Development,  Testing,  Unit  Test, Vitest, Sveltekit

## I. P ENDAHULUAN
Pengembang  perangkat  lunak  pada  saat  ini  dituntut untuk  mengembangkan  perangkat  lunak  dengan  baik  dan benar yang sesuai dengan kebutuhan yang ada. Salah satu faktor yang membuat perangkat lunak tersebut baik adalah bebas dari berbagai macam bug dan program mudah untuk dirawat.  Salah  satu  cara  untuk  mendapatkan  hal  tersebut adalah  menggunakan  metode Test-Driven  Development (TDD) . TDD adalah metode dengan menuliskan pengujian sebelum kode program. Dengan TDD diharapkan memiliki kualitas  kode  yang  baik  dan  bebas  dari  berbagai  macam bug .
Proses  pengembangan  perangkat  lunak,  memiliki beberapa  macam  metodologi  yang  sering  digunakan.
Seperti Agile , Waterfall , Spiral dan  lain-lain  [1].  Adapun TDD merupakan  salah  satu  metode  di  dalam  metodologi Agile [2][3][4]. Agile merupakan sebuah metodologi yang memungkinkan pengembang menyelesaikan proses pengembangan  dalam  waktu  singkat  serta  dapat beradaptasi  dengan  perubahan  [5].  Tujuan  konsep  utama dari TDD adalah untuk menyelesaikan kode menjadi lebih jelas,  sederhana  dan  bebas  dari  berbagai  macam bug [6]. Konsep  ini  melakukan  penulisan unit  test terlebih  dahulu lalu dilanjut penulisan kode program dan diakhiri dengan refactor [7][8].  Metodologi  yang  digunakan  pada TDD adalah unit  test [6].  Jika  dibandingkan  dengan  gaya konvensional  yang  langsung  menuliskan  kode  program, konsep TDD tentu sangat merepotkan. Walaupun terkesan merepotkan  tetapi  konsep  ini  akan  berguna  bagi pengembang  karena  berfokus  pada  pencegahan  akan terjadinya bug pada  perangkat  lunak  ketika  digunakan  di dalam suatu organisasi.
Berdasarkan masalah yang telah dijabarkan diatas, pada paper  ini  akan  dianalisa  dampak  terkait  kualitas  kode dengan  menggunakan  indikator test-driven  development dan non-test-driven development . Matriks yang digunakan adalah code  coverage , cyclomatic  complexity , halstead volume dan maintainability  index .  Harapannya  adalah untuk mengetahui dampak kualitas kode dari metode test- driven development dibandingkan non-test-driven development dengan matriks-matriks diatas.
Dari  hasil  penelitian  Khanam  dan  Ahsan  [9],  ada beberapa fakta terkait metode TDD . Fakta pertama adalah dapat  membantu  pengembang  dalam  menemukan  cacat pada  program  lebih  awal.  Fakta  kedua,  dengan  unit  test yang telah dibuat juga dapat dijadikan sebagai dokumentasi pada  kode  program.  Fakta  ketiga  adalah  dapat  membantu dalam proses maintenance dan refactoring . Keuntungan  menggunakan TDD adalah  peningkatan kualitas kode yang dibuat, meningkatkan code understanding karena seringnya melakukan perbaikan rutin ( refactoring ) dan meningkatkan kecepatan dalam pengembangan  karena  tidak  perlunya  waktu  untuk debugging [9].  Kekurangan  dalam TDD untuk  proses
pengembangan adalah produktivitas yang menurun, harus mempunyai  pengetahuan  dalam refactoring dan  perlunya usaha dan waktu dalam merancang unit test [9].
Tujuan penelitian ini adalah untuk mengetahui beberapa efek  yang  didapatkan  ketika  kita  melakukan  proses pengembangan  menggunakan  metode TDD .  Metriks seperti bugs , code  complexity dan  sejenisnya  akan digunakan sebagai metriks dalam penelitian.
Penelitian terdahulu dilakukan oleh Bakhtiary, Gandomani  dan  Salajegheh  [8],  dimana  pada  penelitian tersebut  mereka  membandingkan  efektifitas  antara TDD dengan Non-TDD .  Penelitian  tersebut  mendapatkan  hasil bahwa  dengan  menggunakan test-driven  development dapat  membuat design  quality lebih  sesuai  dengan  yang diinginkan. Perbedaan dengan penelitian ini adalah terletak pada  hasilnya.  Jika  penelitian  sebelumnya  meneliti beberapa  proyek  dengan  beberapa  tim,  sedangkan  pada penelitian  ini  hanya  berfokus  membangun  ulang  projek yang sudah ada sebelumnya, dengan pendekatan Non-TDD , menjadi dengan pendekatan TDD .
Penelitian lain pernah dilakukan oleh Moe [6], dimana mendapatkan  hasil  bahwa  dengan  menggunakan TDD dapat  memungkinkan  untuk  meningkatkan  nilai  dari test coverage . Test coverage memiliki arti berapa banyak kode yang  telah  dijangkau  oleh test suite .  Hasil  lainnya adalah dengan TDD dapat  mengurangi  kemungkinan  untuk memiliki bug yang  sulit  dilacak.  Perbedaan  dengan penelitian  ini  adalah  pada  penelitian  ini  berfokus  untuk membandingkan code  quality antara test-driven dan non- test-driven .  Sedangkan  pada  penelitian  sebelumnya berfokus  membahas  melakukan  komparasi  teknik  antara test-driven development , behavior-driven development dan acceptance test-driven development .

## II. M ETODE P ENELITIAN

## A. Menentukan Data Pengujian
Tahapan  ini  adalah  dimana  peneliti  mencari  data penelitian untuk nantinya diuji menggunakan metode TDD . Adapun data yang diuji adalah data yang akan didapat dari repository  Github  dengan  lisensi MIT  License .  Data  yang diperoleh adalah repositori milik Riza Fahmi dengan nama repositori  “carikerja”.  Repositori    tersebut  menggunakan bahasa pemrograman Typescript dengan Framework Svelte . Terkait kebutuhaan aplikasi nantinya akan mengikuti atau merujuk dari aplikasi awal yaitu “carikerja”.

## B. Pengembangan Sistem
Metode  yang  digunakan  dalam  penelitan  ini  adalah menggunakan TDD . Adapun tahapan atau fase dalam TDD adalah sebagai berikut:

## Gambar 1 Diagram TDD
Gambar  diatas  merupakan  diagram  dari  proses TDD . Adapun  penjelasan  dari  masing-masing  diagram  item adalah sebagai berikut:
1) Menulis  Unit  Test :  Pada  gambar  diatas,  tahapan ini berwarna merah atau “ writing a failing test ”, atau sering juga  disebut  sebagai red  phase .  Tahapan  yang  dilakukan adalah  pengembang  menuliskan  pengujian  berdasarkan requirement yang  sudah  disediakan. Requirement disini mengacu  kepada  aplikasi  yang  sebelumnya  sudah  ada. Terkait pengujian yang  ditulis  harus  seminimal  mungkin atau  hanya  mengkover  satu  fungsionalitas  saja,  sehingga nantinya  lebih  mudah  untuk  menemukan  kesalahan  pada program. Hasil dari tahapan ini adalah galat pada terminal karena  aplikasi  kita  tidak  memiliki  kode  yang  sesuai dengan test yang sudah ditulis.
2) Implementasi Kode Program : Pada gambar diatas, tahapan  ini  berwarna  hijau  yaitu  “ make  the  test  past ”. Tahapan  ini  bertujuan  untuk  melengkapi  tahapan sebelumnya  yaitu  membuat test suite . Dimana  jika  dalam tahapan  sebelumya,  hasil test akan  merah,  maka  dalam tahapan ini pengembang bertugas untuk membuat terminal yang sebelumnya merah menjadi hijau. Ketika dalam tahap ini,  fokus  pengembang  adalah  membuat  bagaimana  test yang  ditahap  sebelumnya  dibuat  menjadi  bekerja  ( green ) tanpa  terlalu  memikirkan  bagaiana best  practice dalam penulisan kode.
3) Refactoring :  Jika  dalam  tahapan  sebelumnya pengembang  hanya  berfokus  pada  bagaimana  cara membuat terminal yang sebelumnya merah menjadi hijau, dalam tahapan refactoring ini pengembang akan berfokus untuk  melakukan  optimasi  program  ( refactoring ). Harapannya  didapatkan  kualitas  kode  yang  bersih  yang mudah  untuk  dibaca  orang  lain.  Bagaimana  tahapan refactoring bekerja dapat dilihat pada diagram berikut:
Gambar 2 Diagram refactoring
Tahap pertama adalah melihat apakah kode terlihat baik, jika terlihat baik maka akan lanjut ke fitur selanjutnya. Jika
kode  terlihat  tidak  baik,  maka  akan  masuk  ke  tahapan refactor sebelum  nantinya  masuk  ke  fitur  selanjutnya. Tekait pengecekan apakah kode tersebut terlihat baik atau tidak akan menggunakan dua cara, yaitu code review dan menggunakan alat bantu. Dalam code review , pengembang akan  melakukan  analisa  kode  secara  seksama  terhadap sumber kode yang sudah ditulis. Sedangkan alat bantu yang digunakan adalah ESLint dan Prettier untuk formatting dan linting .

## C. Pengujian
Tahapan  ini  adalah  tahapan  dimana  peneliti  akan menguji  aplikasi  yang  telah  dibuat.  Program  yang  telah dibuat akan diuji dengan beberapa pengujian untuk melihat dampak seperti apa jika menggunakan TDD dalam proses pengembangan. Pada tahapan ini variabel yang digunakan dan  diambil  adalah  dari  beberapa tools untuk  pengujian analisa  kode,  seperti SonarQube , Codacy dan  sejenisnya. Detail  untuk  masing-masing  variabel  yang  nanti  didapat adalah sebagai berikut:
1) Code  CoverageCode; adalah reports dari presentase  seberapa  banyak  kode  yang  dijangkau  oleh rangkaian test suite [9]. Tujuan code coverage adalah untuk mengetahui berapa banyak kode yang telah dijangkau oleh test suite . Tahapan ini akan dibantu oleh framework yang disarankan oleh Vitest yaitu C8 atau Istanbul.
2) Code  Complexity: merupakan  sebuah  metriks untuk  mengukur  kompleksitas  dari  sebuah  program. Tujuan  dari code  complexity adalah  untuk  mengetahui kompleksitas  dari  sebuah  kode.  Salah  satu  metode  untuk mengukur  kompleksitas  dari  program  adalah  dengan menggunakan cyclomatic complexity serta halstead metrics . Cyclomatic complexity merupakan penghitungan kompleksitas  program  menggunakan  jumlah  dari  linear independent  path yang  ada  pada  kode  program  [10]. Semakin besar nilanya, semakin sulit kode tersebut untuk dipahami.  Untuk  menghitung cyclomatic complexity akan menggunakan  alat  bantu Code  Metrics dari  extension Visual Studio Code.
Halstead  metrics merupakan  metriks  dimana  proses penghitungannya  berbasis  jumlah  dari operator dan operands [11]. Tujuan dari halstead metrics adalah untuk mengidentifikasi sifat dari perangkat lunak. Adapun rumus untuk menghitung halstead metrics adalah sebagai berikut [12]  : 𝑝𝑟𝑜𝑔𝑟𝑎𝑚 𝑙𝑒𝑛𝑔𝑡ℎ = 𝑁1 + 𝑁2 𝑝𝑟𝑜𝑔𝑟𝑎𝑚 𝑣𝑜𝑐𝑎𝑏𝑢𝑙𝑎𝑟𝑦 =  𝜂1 +  𝜂2 𝑣𝑜𝑙𝑢𝑚𝑒 = 𝑝𝑟𝑜𝑔𝑟𝑎𝑚 𝑙𝑒𝑛𝑔𝑡ℎ ∗ 𝑙𝑜𝑔 2 (𝑝𝑟𝑜𝑔𝑟𝑎𝑚 𝑣𝑜𝑐𝑎𝑏𝑢𝑙𝑎𝑟𝑦)
𝑑𝑖𝑓𝑓𝑖𝑐𝑢𝑙𝑡𝑦 = 𝑛1 2 × 𝑁2 𝑛2 𝑒𝑓𝑓𝑜𝑟𝑡 = 𝐷  × 𝑉
𝑒𝑥𝑝𝑒𝑐𝑡𝑒𝑑 𝑏𝑢𝑔 = 𝑉 3000 3) Maintainability Index: merupakan sebuah patokan  ke  biaya  dalam  proses  pemeliharaan.  Tujuan tahapan ini adalah untuk mengetahui berapa besar dari nilai dari maintainability  index .  Semakin  tinggi  nilai  yang didapat  semakin  bagus  dalam maintainability program yang dibuat. Untuk mendapatkan nilai dari maintainability index ,  peneliti  perlu  menggunakan  nilai  dari  tahapan sebelumnya  yaitu cyclomatic  complexity dan halstead
metrics . Adapun formula untuk tahapan ini adalah sebagai berikut [13][14] :
𝑀𝐼 = 𝑀𝐴𝑋(0, (171 − 5.2 × ln(𝐻𝑉) − 0.23 × 𝐶𝐶 − 16.2 × ln(𝐿𝑂𝐶)) × 100/171)
HV merupakan  nilai  dari halstead  metrics , CC adalah nilai dari cyclomatic complexity serta LOC adalah nilai dari line of code . Dari nilai yang didapatkan akan diperoleh nilai dari maintainability  index ,  dimana  nilai  tersebut  dapat diklasifikasikan sebagai berikut [15][16]:
TABEL I K LASIFIKASI N ILAI M AINTANABILITY I NDEX Nilai MI Klasifikasi MI ≥ 20 Green ( High Maintainability) 10 ≤ MI < 20 Yellow (Moderately Maintainability) MI ≤ 10

## Red (Low Maintainability) III. H ASIL DAN P EMBAHASAN
Pembahasan  pada  bab  ini  akan  dibagi  menjadi  tiga bagian  yaitu code  coverage , halstead  metrics dan maintainability index . Hasil dari nilai yang diperoleh akan ditampilkan dalam bentuk tabel untuk nantinya dibandingkan antara TDD dengan Non-TDD .

## A. Code Coverage
Tahapan  ini  adalah  tahapan  dimana  akan  dilakukan perhitungan code  coverage menggunakan  Istanbul. Tahapan code coverage dilakukan untuk mengetahui nilai dari seberapa banyak kode yang sudah dijangkau oleh test suite .  Pada  Tabel  2  ditunjukan  nilai  dari code  coverage antara  TDD  dan Non-TDD .  Hasil  yang  didapat menunjukkan  bahwa  dengan  pendekatan  TDD,  dapat meningkatkan nilai dari code coverage suatu program.
TABEL II H ASIL N ILAI C ODE C OVERAGE No Coverage TDD Non-TDD 1 Statements 94.68 13.09 2 Branch 77.46 86.11 3 Functions 100 10.81 4 Lines 95.67 13.09
Dari  Tabel  2  didapatkan  hasil  semakin  tinggi  nilai coverage dari  sebuah  program,  semakin  tinggi  juga  kode tersebut  sudah  dijangkau  oleh test  suite .  Semakin  tinggi nilai dari nilai coverage , semakin kecil juga kode tersebut terdapat bug didalamnya.
TABEL III H ASIL R ATA - RATA N ILAI C ODE C OVERAGE No Metode Coverage 1 Test-driven development 92.17 2 Non-test-driven development 30.775
Pada  Gambar  3  ditunjukan  bahwa  nilai coverage meningkat  secara  pesat.  Jika  sebelum  menggunakan test- driven  development nilai coverage hanya  ±30,  setelah menggunakan test-driven  development nilai  tersebut meningkat  drastis  sampai  menyentuh  angka  ±92.  Angka tersebut  mencapai  33.37%,  dimana  memiliki  arti  dengan pendekatan TDD , test  suite yang  telah  dibuat  hampir menjangkau  seluruh  kode  program.  Hal  ini  terjadi  karena ketika  menggunakan TDD ,  fokus  utama  pengembang adalah pembuatan unit test . Dari unit test tersebut nantinya
akan dijadikan sebagai patokan atau awal dalam tiap siklus pengembangan TDD .
Gambar 3 Perbandingan hasil rata-rata code coverage

## B. Cyclomatic Complexity
Tahapan  ini  mengukur cyclomatic  complexity dari masing-masing  pendekatan  antara TDD dan Non-TDD pada  repositori  Github  “Carikerja”.  Tabel  4  merupakan hasil  dari  perhitungan cyclomatic  complexity dari  seluruh kode program.
TABEL IV H ASIL N ILAI C YCLOMATIC C OMPLEXITY
No Metode CC 1 Test-driven development 38 2 Non-test-driven development 44
Pada Gambar 4 menunjukkan bahwa dengan menggunakan test-driven  development dapat  mengurangi nilai dari cyclomatic complexity dari sebuah program. Pada grafik  menunjukkan  jika  nilai cyclomatic  complexity menurun ±15.78%.
Gambar 4 Perbandingan hasil cyclomatic complexity

## C. Halstead Metrics
Tahap  ini  akan  menghitung  nilai  dari halstead  metric antara test-driven  development dan non-test-driven development .  Terkait  metriks  yang  digunakan  seperti program  length , vocabulary  of  program , volume  of program , difficulty ,  effort  dan number  of  bug  expected . Tabel  5  merupakan  perhitungan halstead  volume dari kedua metode.
TABEL V
P ERHITUNGAN H ALSTEAD M ETRICS
No Metode Matriks Perhitungan 1 TDD Program length = 𝑁1 + 𝑁2 = 45 + 69 = 114 Vocabulary of program = 𝜂1 +  𝜂2 = 12 + 38
= 50
Volume of program = 𝑝𝑟𝑜𝑔𝑟𝑎𝑚 𝑙𝑒𝑛𝑔𝑡ℎ ∗ 𝑙𝑜𝑔 2 50 = 114 ∗ 𝑙𝑜𝑔 2 50
≈ 643.5196 Difficulty = 𝑛1 2 × 𝑁2 𝑛2 = 12 2 × 45 38 ≈ 7.1052 Effort = 𝐷  ×  𝑉 = 7.1052 ×  643.5196 ≈ 4567.5336 Number of bugs expected = 𝑉 3000 = 643.5196 3000 ≈ 0.214
2 Non-
TDD Program length
= 𝑁1 + 𝑁2 = 56 + 90 = 146 Vocabulary of program = 𝜂1 +  𝜂2
= 15 + 48 = 63 Volume of program = 𝑝𝑟𝑜𝑔𝑟𝑎𝑚 𝑙𝑒𝑛𝑔𝑡ℎ ∗ 𝑙𝑜𝑔 2 50
= 146 ∗ 𝑙𝑜𝑔 2 63 ≈ 876.94548 Difficulty
= 𝑛1 2 × 𝑁2 𝑛2 = 15 2 × 56 48
≈ 8.75 Effort = 𝐷  ×  𝑉 = 8.75 ×  876.94548 ≈ 7670.6479 Number of bugs expected = 𝑉 3000 = 876.94548 3000 ≈ 0.292
Tabel 6 merupakan rangkuman pengujian seluruh kode program dari kedua metode. Hasil yang didapatkan adalah dengan  menggunakan  metode TDD dapat  meningkatkan seluruh halstead metriks pada kode perangkat lunak.
TABEL VI H ASIL N ILAI H ALSTEAD M ETRICS Metrics TDD Non-TDD Program length 114 146 Vocabulary of program 50 63 Volume of program 643.482 868.869 Difficulty 7.105 8.75 Effort 4566.586 7600.763 Number of bugs expected 0.214 0.292
Gambar  5  merupakan  nilai  dari program  length dari masing  masing  metode.  Didapatkan  bahwa  dengan menggunakan test-TDD dapat  membuat program  length menjadi lebih ringkas. Tentunya dengan hal tersebut dapat
20 40 60 80 100 Non-TDD TDD Code Coverage Code Coverage 35 40 45 TDD Non-TDD Cyclomatic Complexity
Cyclomatic Complexity
membuat  kode  lebih  mudah  untuk  dibaca.  Hal  ini  terjadi karena dalam tahapan refactoring sering melakukan reduce beberapa  variabel  atau  fungsi  yang  seharusnya  tidak digunakan atau bisa lebih dioptimasi.
Gambar 5 Perbandingan program length
Gambar 6 merupakan nilai dari vocabulary of program dari  kedua  metode.  Hasilnya  dengan  menggunakan TDD dapat  mengurangi  nilai vocabulary  of  program dengan kisaran  35%  dari  nilai  awal.  Hal  ini  terjadi  karena  dalam tahapan refactoring sering  melakukan reduce beberapa variabel atau fungsi yang seharusnya tidak digunakan atau bisa lebih dioptimasi yang ada pada program.
Gambar 6 Perbandingan vocabulary of program
Gambar  7  merupakan  hasil  dari volume  of  program antara  kedua  metode.  Hasil  yang  didapat  adalah  dengan menggunakan TDD , dapat mengurangi volume of program berkisar ±35%. Hal ini terjadi karena dalam tahapan TDD pengembang  berfokus  pada  fungsionalitas  pada test yang dilakukan  secara  unit.  Jadi  pengembang  berfokus  kepada bagaimana  membuat  sebuah  kode  sederhana  yang  bisa membuat atau memenuhi kebutuhan test yang sebelumnya sudah  ditulis.  Itulah  yang  membuat volume  of  program menjadi lebih kecil.
Gambar 7 Perbandingan volume of program
Gambar 8 merupakan perbandingan nilai dari difficulty antara  kedua  metode.  Didapatkan  hasil  bahwa  dengan metode TDD ,  dapat  mengurangi difficulty sebesar  ±23%. Hal  tersebut  terjadi  karena  pada TDD memiliki  nilai operator dan operand yang lebih sedikit daripada non-test- driven development.
Gambar 8 Perbandingan difficulty
Gambar  9  merupakan  hasil  dari effort antara  kedua metode.  Hasil  yang  didapat  adalah  dengan  menggunakan TDD dapat mengurangi nilai effort sebesar ±66%. Hal ini terjadi karena dengan TDD , nilai dari difficulty dan volume lebih kecil dari penggunanakan Non-TDD .
Gambar 9 Perbandingan efforts
Gambar  10  merupakan  nilai  dari bug  expected antara kedua  metode.  Hasil  yang  didapat  adalah  dengan menggunakan TDD ,  dapat  mengurangi  nilai  dari bug expected .  Nilai  awal  sebesar  0.214  berkurang  menjadi 0.292  atau  ±39%.  Hal  ini  terjadi  karena  dengan menggunakan  pendekatan TDD ,  nilai  volume  lebih  kecil karena  kompleksitas  kode  yang  juga  lebih  kecil  daripada menggunakan Non-TDD .
100 120 140 160 Non-TDD TDD Program Length Program Length 30 40 50 60 70 Non-TDD TDD Vocabulary of Program Vocabulary of Program 550 650 750 850 Non-TDD TDD Volume of Program Volume of Program 6.00 8.00 10.00 Non-TDD TDD Difficulty Difficulty 4,000 5,000 6,000 7,000 8,000 Non-TDD TDD Efforts Efforts
Gambar 10 Perbandingan number of bugs expected

## D. Maintainability Index
Tahapan  ini  adalah  mengukur  antara test-driven development dengan non-test-driven development . Tabel 7 merupakan  nilai  yang  sudah  didapatkan  pada  tahap sebelumnya  untuk  nantinya  menjadi  376 ariable  dalam tahap perhitungan maintainability index .
TABEL VII N ILAI U NTUK P ERHITUNGAN M AINTAINABILITY INDEX Metrics TDD Non-TDD Line of code 458 512 Cyclomatic complexity 38 44 Halstead volume 643.482 868.869
Setelah  mendapatkan  nilai-nilai  seperti line  of  code , cyclomatic  complexity dan halstead  volume ,  maka dilanjutkan  dengan  memasukkan  nilai-nilai  tersebut  pada rumus maintainability  index .  Adapun  untuk  nilai  dari masing masing metode adalah sebagai berikut :
𝑻𝑫𝑫  = 𝑀𝐴𝑋 (0, (171 − 5.2 ×𝑙𝑛 (643.482)  − 0.23 × 38
− 16.2 × ln(458)) × 100 171 ) = 𝑀𝐴𝑋 (0, (171 − 5.2 ×6.46609  −0.23 × 38 − 16.2 × 6.128) × 100 171 )
= 𝑀𝐴𝑋 (0, (171 − 33.623668  − 8.74 − 99.2736)
× 100 171 ) = 𝑀𝐴𝑋 (0, (29,362732) × 100 171 ) = 17.1711
𝑵𝒐𝒏𝑻𝑫𝑫       = 𝑀𝐴𝑋 (0, (171 − 5.2 ×𝑙𝑛 (868.869) − 0.23 × 44
− 16.2 × ln(512))
× 100 171 ) = 𝑀𝐴𝑋 (0, (171 − 5.2 ×6.7671 −0.23 × 38
− 16.2 × 6.23832) × 100 171 )
= 𝑀𝐴𝑋 (0, (171 − 35.18892 − 8.74
− 101.060784)
× 100 171 ) = 𝑀𝐴𝑋 (0, (26.010296) × 100 171 )

## = 15.2106
Tabel 8 merupakan hasil dari maintainability index dari kedua  metode.  Didapatkan  dengan  menggunakan test- driven  development ,  nilai  dari maintainability  index menjadi lebih tinggi.
TABEL VIII H ASIL N ILAI M AINTAINABILITY INDEX
No Metode MI 1 Test-driven development 17.1711 2 Non-test-driven development 15.2106
Gambar  11  merupakan  hasil  nilai  dari  kedua  metode. Didapatkan hasil dengan menggunakan metode TDD dapat meningkatkan  nilai  dari maintainability  index .  Hasil  dari kedua  nilai  tersebut  masuk  dalam  kategori yellow yang berarti  kode  tersebut  masuk  dalam  kategori moderately maintainability .  Walaupun  hasilnya  masuk  ke  dalam kategori yellow ,  tetapi  dengan  pendekatan  TDD  dapat meningkatkan  nilai  dari maintainability  index sebesar ±11%.
Gambar 11 Perbandingan maintainability index

## IV. K ESIMPULAN
Dari hasil penelitian yang sudah dilakukan, maka dapat ditarik  kesimpulan  bahwa  enggunaan TDD dapat meningkatkan  nilai  dari code  coverage .  Nilai  yang didapatkan cukup signifikan karena penggunaan penggunaan TDD dapat  meningkatkan coverage kode hampir 33.37%. Hal ini terjadi karena pengembang fokus mengembangkan  perangkat  berdasarkan test  suite . Kemudian  TDD  dapat  mengurangi  nilai  dari cyclomatic complexity . Walaupun tidak terlalu signifikan, tetapi nilai menurun sekitar 15.78%. Hal ini terjadi karena pada setiap siklus TDD terdapat tahapan refactoring program sehingga mengurangi  penggunaan  beberapa  kode  yang  tidak diperlukan.  Nilai  dari program  length , vocabulary  of program , volume of program , difficulty , effort dan number of  bug  expected menurun  ketika  menggunakan  metode TDD .  Hal  ini  terjadi  karena  pada TDD ada  tahapan refactoring pada  setiap  siklus  sehingga  kode  program
0.00 0.20 0.40 Non-TDD TDD Number of Bugs Expected Number of Bugs Expected 14.00 15.00 16.00 17.00 18.00 Non-TDD TDD Maintainability Index Maintainability Index
menjadi  lebih  efektif  dan  efisien  dalam  penulisan.  Nilai maintainability  index juga  menurun  ketika  menggunakan metode TDD .  Walaupun  tidak  signifikan,  tetapi  dengan menggunakan TDD dapat membuat nilai dari maintainability index menjadi lebih baik.

## R EFERENSI
[1] Y.  Qamsane et  al. , “A  Methodology to Develop and Implement Digital Twin Solutions for Manufacturing Systems,” IEEE Access ,
vol. 9, pp. 44247–44265, 2021, doi:
10.1109/ACCESS.2021.3065971.
[2] S.  Al-Saqqa,  S.  Sawalha,  and  H.  Abdelnabi,  “Agile  software development:  Methodologies  and  trends,” International  Journal of Interactive Mobile Technologies , vol. 14, no. 11, pp. 246–270, 2020, doi: 10.3991/ijim.v14i11.13269.
[3] S. Romano, F. Zampetti, M. T. Baldassarre, M. Di Penta, and G. Scanniello,  “Do  Static  Analysis  Tools  Affect  Software  Quality when  Using  Test-driven  Development?,”  in International Symposium on Empirical Software Engineering and Measurement , IEEE  Computer  Society,  Sep.  2022,  pp.  80–91.  doi: 10.1145/3544902.3546233.
[4] R.  Goldan,  Y.  Elzatar,  A.  Hendra  Brata,  and  A.  P.  Kharisma, “Pengembangan Sistem Informasi Inventarisasi Aset menggunakan  Metode  Test  Driven  Development  (Studi  Kasus: Universitas  Mulia),”  2022.  [Online].  Available:  http://j- ptiik.ub.ac.id
[5] A. Nur, A. Thohari, and A. E. Amalia, “IMPLEMENTASI TEST DRIVEN  DEVELOPMENT  DALAM  PENGEMBANGAN APLIKASI BERBASIS WEB.” [Online]. Available: http://jurnal.umk.ac.id/index.php/sitech
[6] M. M. Moe and J. C. Sanchez, “Comparative Study of Test-Driven Development (TDD), Behavior-Driven Development (BDD) and Acceptance  Test-Driven  Development  (ATDD),” International Journal of Trend in Scientific Research and Development , vol. 3, no. 4, 2019, [Online]. Available:
http://creativecommons.org/licenses/by/4.0
[7] Jamalludin, H. Yuliansyah, S. Winiati, I. Riadi, U. Ahmad Dahlan, and J. ProfDr Supomo, “Implementasi Test Driven Development Pada  Pengembangan  Aplikasi  Android  Untuk  Mahasiswa Universitas  Ahmad  Dahlan,”  2018.  [Online].  Available: http://simeru.uad.ac.id
[8] V.  Bakhtiary,  T.  J.  Gandomani,  and  A.  Salajegheh,  “The effectiveness  of  test-driven  development  approach  on  software projects: A multi-case  study,” Bulletin of Electrical Engineering and  Informatics ,  vol.  9,  no.  5,  pp.  2030–2037,  Oct.  2020,  doi: 10.11591/eei.v9i5.2533.
[9] Z.  Khanam  and  M.  N.  Ahsan,  “Evaluating  the  Effectiveness  of Test Driven Development: Advantages and Pitfalls,” International Journal of Applied Engineering Research , vol. 12, pp. 7705–7716, 2017, [Online]. Available: http://www.ripublication.com
[10]  M.  A.  Rizkyana,  A.  Yunanto,  A.  Herdian,  and  Y.  R.  Ainul, “Implementasi  Unit  Testing  Menggunakan  Metode  Test-First Development,” vol. 7, no. 1, 2021.
[11]  M. Ivankovi, G. Petrovi, R. Just, and G. Fraser, “Code coverage at Google,” in ESEC/FSE 2019 - Proceedings of the 2019 27th ACM Joint  Meeting  European  Software  Engineering  Conference  and Symposium  on  the  Foundations  of  Software  Engineering , Association for Computing Machinery, Inc, Aug. 2019, pp. 955– 963. doi: 10.1145/3338906.3340459.
[12]  R. A. Wijaya and K. Karmilasari, “Pengukuran Kualitas Website Pengurus  Cabang  NU  Depok  Menggunakan  Software  Metric,” Jurnal Sisfokom (Sistem Informasi dan Komputer) , vol. 10, no. 3, pp. 438–443, Dec. 2021, doi: 10.32736/sisfokom.v10i3.1267.
[13]  R.  Ganang  Atmaja,  B.  Priyambadha,  and  F.  Pradana, “Pembangunan  Kakas  Bantu  Untuk  Mengukur  Maintainability Index Pada Perangkat Lunak Berdasarkan Nilai Halstead Metrics dan  McCabe’s  Cyclomatic  Complexity,”  2019.  [Online]. Available: http://j-ptiik.ub.ac.id
[14]  D.  R.  Wijendra  and  K.  P.  Hewagamage,  “Analysis  of  Cognitive Complexity with Cyclomatic Complexity Metric of Software,” Int J  Comput  Appl ,  vol.  174,  no.  19,  pp.  14–19,  Feb.  2021,  doi: 10.5120/ijca2021921066.
[15]  G. H. Kencana, A. Saleh, H. A. Darwito, R. R. Rachmadi, and E. M. Sari, “Comparison of maintainability index measurement from microsoft codelens and line of code,” in International Conference on  Electrical  Engineering,  Computer  Science  and  Informatics (EECSI) ,  Institute  of  Advanced  Engineering  and  Science,  Oct.
2020, pp. 235–239. doi: 10.23919/EECSI50503.2020.9251901.
[16]  S.  Kadi,  “Measuring  Maintainability  and  latency  of  Node.js frameworks,” 2021. Accessed: Jun. 18, 2023. [Online]. Available: https://www.diva- portal.org/smash/get/diva2:1598017/FULLTEXT02