Malas Melakukan Test Driven Development? Coba Pikir Ulang

Test It!

Test Driven Development merupakan salah satu hal yang terlambat untuk saya pelajari maupun terapkan. Tentunya, terdapat penyesalan karenanya.

Motivasi

Awalnya nggak begitu peduli sama yang namanya testing. Selain karena kurang paham sama hal teknisnya, saya pikir testing itu hanya membuang-buang waktu. Kita harus menulis code buat testing code :v terus buat apa repot-repot bikin testing code kalo kita bisa melakukan testing via browser atau media lain? Mending langsung aja test! Awalnya sih begitu~

Sampailah pada titik dimana ada kejenuhan dan kejengkelan saat melakukan testing manual — via browser. Pada saat itu ada case dimana harus melakukan testing pada sekian form dan inputannya nggak sedikit ._. Gara-gara hal tersebut, waktu ngodingnya malah habis buat ngisi form yang bejibun — waktu itu nggak ada click tester jadi developernya harus testing sendiri :( Sebenernya nggak capek sih, tapi jengkel aja ketika harus ngetik “asd asd asd asd qwe qwe qwe qwe zxc zxc zxc” pada setiap input yang ada, terus pas kita submit yang muncul malah error. Aaarrggghhh!

Nah kebetulan di timeline ada yang share soal Jest jadi langsung kepoin si Jest besutan facebook ini. Setelah baca sekilas, ternyata Jest ini adalah sebuah testing framework yang digunakan facebook untuk melakukan testing pada setiap app-nya. Mulailah sedikit muncul keinginan untuk melakukan testing tapi masih belum paham apa sebenernya manfaat testing tersebut :(

Untungnya, setelah sekian artikel yang dibaca. Mulai tuh muncul gambaran tentang manfaat testing. Dan ternyata manfaatnya itu bikin kita gak capek.

Mengekspektasikan Bug

Pada saat testing itu, kita dilatih untuk lebih peka pada error yang bakalan terjadi. Jadi, sebelum bug itu benar-benar terjadi, kita sudah tau kalau bakalan ada bug itu di app kita. Tinggal mikirin aja bagamana cara mengatasinya. Contohnya nih anggap saja kita mau bikin function yang funsinya untuk menggantikan value yang kosong menjadi tanda (-).

function kosongToStrip (val) {   
  return val === "" ? "-" : val
}

Kalau kita tidak menggunakan TDD (Testing Driven Development), mungkin bugnya nggak bakal keliatan pada awalnya. Sampai ada saat dimana app kita menjalankan function tersebut dengan value null.

kosongToStrip("Aman?") // Aman?
kosongToStrip("") // -
kosongToStrip(null) // null

Apa itu yang dinginkan? Enggak kan? yang diinginkan itu null juga menjadi strip (-). Oke terus kita beresin tuh bug-nya.

function kosongToStrip (val) {   
  var kosong = val === ""  
  var isinyaNull = val === null
  return kosong || isinyaNull ? "-" : val
}

Sip! dan testing manual lagi….

kosongToStrip("Aman?") // Aman?
kosongToStrip("") // -
kosongToStrip(null) // -

Alhamdulillah beres. Deploy ulang deh App-nya. Anggaplah semuanya baik-baik saja. Function tersebut akhirnya dipakai hampir di seluruh halaman pada App. Sampai App tersebut menjalan function tersebut dengan value NaN. Bug!

kosongToStrip("Aman?") // Aman?
kosongToStrip("") // -
kosongToStrip(null) // -
kosongToStrip(NaN) // NaN

Beresin lagi bugnya….

function kosongToStrip (val) {
  var kosong = val === ""  
  var isinyaNull = val === null
  var isinyaNaN = val === NaN
  return kosong || isinyaNull || isinyaNaN ? "-" : val
}

Kayaknya udah gak ada bug deh :/ Deploy ulang App-nya dan jangan lupa testing manual lagi.

kosongToStrip("Aman?") // Aman?
kosongToStrip("") // -
kosongToStrip(null) // -
kosongToStrip(NaN) // -

Satu dua hari App kita berjalan lancar, sampai function tersebut dijalankan dengan value undefined.

kosongToStrip("Aman?") // Aman?
kosongToStrip("") // -
kosongToStrip(null) // -
kosongToStrip(NaN) // -
kosongToStrip(undefined) // undefined

Untuk kesekian kalinya, kita melakukan perbaikan

function kosongToStrip (val) {
  var kosong = val === ""  
  var isinyaNull = val === null
  var isinyaNaN = val === NaN
  var isinyaUndefined = val === undefined
  return kosong || isinyaNull || isinyaNaN || isinyaUndefined ? "-" : val
}

Apa udah solved? Belum tentu. Itukan masih satu function. Bagaimana dengan function yang lain yang saling berhubungan satu sama lain? Dan biasanya testing manual itu dilakukan dengan cara menjalankan app kita terus kita coba di real UI-nya atau di console berulang kali. Itu yang bikin capek!

Tulis Speknya Dulu, Baru Coding

Dengan TDD kita bisa menghindari hal-hal seperti contoh kasus di atas. Gimana caranya? Yaa caranya kita tulis dulu speknya. Apa yang kita mau bikin, bagaimana standarnya, bagaimana cara kerjanya, dll. Masih contoh yang sama. Tapi kita tulis dulu speknya.

// test.spec.js
describe("kosongToStrip()", function () {
  it("Harus Return strip jika kosong", function () {
    var hasil = kosongToStrip("")          
    expect(hasil).toBe("-")   
  })
  
  it("Harus Return Isinya Jika Tidak Kosong", function () {
     var hasil = kosongToStrip("Ada Isinya")             
     expect(hasil).toBe("Ada Isinya")
  })
   
  it("Harus Return strip jika undefined, null, maupun NaN", function () {
     var isinyaUndefined = kosongToStrip(undefined)
     var isinyaNull = kosongToStrip(null)
     var isinyaNaN = kosongToStrip(NaN)
     expect(isinyaUndefined).toBe("-")  
     expect(isinyaNull).toBe("-")     
     expect(isinyaNaN).toBe("-")   
  })
}

Nah, ngodingnya itu saat testingnya jalan. Pas testingnya kita jalanin, testing harus return strip jika undefined, null, maupun NaN bakal error dan muncul message.

undefined expect to be “-”

Itu artinya gimana caranya membuat undefined menjadi “-”. Solusinya adalah menambakan kodingannya.

function kosongToStrip (val) {
  var kosong = val === ""  var isinyaUndefined = val === undefined
  return kosong || isinyaUndefined ? "-" : val
}

Ketika disimpan, maka error itupun langsung muncul. Kali ini bunyinya berbeda.

null expect to be “-”

Segera benerin lagi, dan ketika save akan muncul error lagi.

NaN expect to be “-”

Lalu kita benerin lagi. Akhirnya bug itupun sirna…

Terus Bedanya apaaaaa!!???

Bedanya adalah yang case pertama, kita harus testing secara manual. Sedangkan Case kedua, kita bisa melakukan testing secara otomatis (Automated Testing) menggunakan suatu testing framework. Cara berpikirnya pun berbeda. Yang awalnya ngoding dulu terus cari bug, diganti dengan cari bug dulu — Tulis spek — baru ngoding sambil tracking error di testing console satu persatu. Tanpa Manual Testing!

Konklusi

Manfaat Testing Driven Development ini adalah bakal bikin App kita minim bug dan kita dari sisi developernya pun nggak capek-capek amat. Gak percaya? Coba aja!

Penutup

Setiap detil isi konten dalam artikel ini tidak bermaksud untuk show off,menyinggung, menyindir ataupun sejenisnya. Melainkan hanya berupaya untuk mengajak temen-temen developer supaya membiasakan TDD (Test Driven Development) demi kebaikkan semua. Baik yang bikin projek maupun yang nerusin (maintenance) projek.

Sangat terbuka untuk kritik dan saran. Kalau saya salah, mohon dengan sangat untuk diingatkan. Semoga bermanfaat dan jangan upa Like and Share~

Let’s talk about some projects with me

Just Contact Me At:

• Email: bosnaufalemail@gmail.com
• Skype Id: bosnaufal254
• twitter: @BosNaufal