 |
| Sumber gambar: force.com |
Termasuk dalam hal membuat testclass. Selama ini aku anggap testclass hanya sebagai basa-basi, formalitas agar aplikasi bisa di-deploy ke production. Soalnya system mewajibkan minimal code coverage 75%, baru bisa di-deploy. Tentu saja ini hal yang menjengkelkan dan membuat frustrasi. Hal ini diperparah dengan kebiasaanku yang tidak pernah membaca teori tentang test class ataupun cara yang benar untuk membuat test class. Jadinya asal jadi saja, yang penting bisa di-deploy.
Masalah muncul ketika kerumitan memperoleh code coverage dikombinasikan dengan adanya berbagai governor limit, terutama SOQL limit. Secara standard, dalam satu alur eksekusi, salesforce membatasi hanya boleh ada 100 kali query untuk mengambil data (SELECT). Ini termasuk query yang terjadi dalam trigger, yang mungkin memicu rangkaian trigger dari object lain yang terpengaruh. Oke lah, dalah prakteknya aku bisa paham, karena sifatnya multi-tenant, jadi masing-masing tidak boleh mendominasi resource. Tapi ini kan cuma test class.
Kejengkelanku bertambah karena ternyata di dalam test class, penerapan governor limit itu merupakan akumulasi dari seluruh proses awal. Jadi misalnya aku ada melakukan insert record untuk 3 object berbeda, selama itu masih dalam satu fungsi testclass, akan dianggap sebagai satu eksekusi proses dan akumulasi penggunaan resource akan dikontrol dengan governor limit. Padahal dalam prakteknya, sangat mustahil proses itu berjalan sekaligus. Biasanya user akan insert record A, kemudian pindah menu untuk insert record B, dan terakhir pindah menu untuk insert record C. Jadi dalam prakteknya akan ada 3 eksekusi, yang masing-masing memiliki penggunaan resource yang terpisah. Payahnya, seringkali aku harus membuat testclass untuk object X, dimana untuk bisa membuat record object X itu perlu terlebih dahulu dibuat record untuk object A, B, C, D dst. Pokoknya prosesnya panjang. Kadang baru sampai di pembuatan record D saja sudah mentok kena governor limit.
Salah satu cara untuk mengakali adalah dengan memanfaatkan @isTest(SeeAllData=true) supaya bisa memanfaatkan data yang sudah ada untuk membuat test class bagi trigger/class yang aku buat. Keuntungannya adalah aku tidak perlu melewati tahap insert record A, B, C karena asumsi record sudah ada. Kekurangannya jelas kita harus memastikan bahwa data untuk dipakai itu sudah ada, kalau gak ada ya test classnya jadi mubazir, dan ujung-ujungnya bisa gagal mencapai code coverage 75%. Sejauh ini teknik ini banyak membantu. Teknik lain adalah dengan memecah-mecah test class menjadi beberapa fungsi testclass, karena setiap fungsi akan di-reset perhitungan governor limitnya. Ini juga cukup membantu, asalkan alur prosesnya tidak terlalu panjang.
Tapi hari ini aku kembali mentok, gara-gara kena governor limit. Padahal sudah pakai SeeAllData, dan prosesnya pun tergolong pendek. Entah kenapa tetap saja kena query limit. Iseng-iseng aku nyeletuk di twitter, eh kok ada yang membalas, katanya soal test class itu cuma masalah pengalaman, kalau sudah terbiasa akan menjadi "piece of cake". Busyet .... pengen lempar asbak rasanya. Untung aku gak ngerokok :D
Setelah hampir seharian ngoprek, sampai lebih dari 10 kali mencoba melakukan deployment dan masih gagal, aku coba cari solusi di internet. Di situlah aku nemu tentang fungsi startTest() dan stopTest(). Lebih lengkapnya Test.startTest() dan Test.stopTest(). Rupanya aku bisa menggunakan ini untuk menentukan bagian mana yang aku anggap untuk testing, dan saat mulai memanggil startTest itu, perhitungan governor limit akan di-reset. Jadi aku bisa mengumpulkan data dulu, bikin record A, B, C misalnya, baru waktu mau mulai bikin record X, aku panggil startTest(). Dan hasilnya .... mujarab! Masalah governor limit teratasi. Jadi sekarang aku punya 3 senjata :
- Menggunakan SeeAllData=true
- Memecah menjadi beberapa fungsi testclass
- Menggunakan StartTest dan StopTest
Oh ya, sepertinya aku harus lebih banyak baca teori. Jadi mendingan aku salin saja "Testing Best Practice" sebagai pengingat (dengan sedikit improvisasi, bukan sekedar terjemahan)
- Capailah coverage sebanyak mungkin, untuk setiap kelas. Jadi jangan hanya mengandalnya total rata-rata, yang minimal 75%
- Jika ada logika kondisi (if, case dsb), usahakan untuk membuat test class untuk setiap kondisi
- Lakukan pemanggilan fungsi dengan inputan data yang benar maupun yang tidak benar
- Pastikan testclass tidak menghasilkan error, kecuali kalau errror itu bisa dijebak dengan benar (tidak menimbulkan fatal error)
- Pastikan menangani setiap peluang kesalahan (exception) dengan benar, tidak hanya menjebaknya.
- Gunakan metode System.assert untuk memastikan kode program berperilaku dengan benar
- Gunakan metode RunAs untuk melakukan pengujian dengan berbagai profil yang berbeda
- Latih dengan menggunakan data yg banyak, minimal 20 record dalam testing yang dibuat
- Gunakan ORDER BY untuk memastikan hasil yang diinginkan dalam urutan yang sesuai
- Jangan berasumsi bahwa Record ID itu pasti berurutan
- Kumpulkan data yang diperlukan sebelum membuat kode untuk testing, dan setelah itu baru panggil fungsi Test.startTest().
- Buat komentar selengkap mungkin, tidak hanya tujuan pengujian, melainkan juga data awal dan data akhir yang diharapkan, perkecualian dan lain-lain.
- Buat test class untuk masing-masing kelas secara terpisah, jangan hanya membuat satu test class untuk seluruh aplikasi.
Setidaknya dalam 3 tahun pengalaman ngulik force.com ini, sudah 50% dari saran-saran diatas yang aku ikuti hehehe..... perlu lebih disiplin lagi nih :)
Update:
Ada satu fungi yang belakangan aku temukan adalah Test.isRunningTest(), untuk mengetahui apakah yang menjalankan code adalah program test atau bukan. Jadi ada baiknya, di class/trigger yang menggunakan penggalan code yang tidak bisa ditest, seperti callout, diabaikan saat test.
Update:
Ada satu fungi yang belakangan aku temukan adalah Test.isRunningTest(), untuk mengetahui apakah yang menjalankan code adalah program test atau bukan. Jadi ada baiknya, di class/trigger yang menggunakan penggalan code yang tidak bisa ditest, seperti callout, diabaikan saat test.
Comments