[PMPL Sprint 1 Reflexion] Implementasi Riwayat Unduh DIGIPUS

6 min readOct 16, 2020

Introduction

Banyak sekali jenis materi edukasi, mulai dari matematika, tata boga, militer, dll. Tentunya perbedaan jenis materi edukasi ini ditujukan untuk kelompok individu yang berbeda. Contohnya materi matematika biasanya ditujukan untuk siswa yang masih mengampu sekolah, materi tata boga ditujukan untuk ibu rumah tangga yang mungkin butuh resep. Terkadang, suatu individu cukup kesulitan untuk mendapatkan materi sesuai dengan jenis yang diinginkan. Perlu semacam digital library yang mengorganisir materi, sehingga dengan mudah didapatkan oleh individu yang membutuhkan. Salah satu sistem tersebut adalah DIGIPUS.

DIGIPUS adalah aplikasi berbasis web yang mengakomodasi kebutuhan penyimpanan materi edukasi dari berbagai sumber seperti aparat, akademik, praktisi, hingga organisasi. Penyimpanan dilakukan secara terorganisir sehingga dapat bermanfaat oleh masyarakat secara luas. Aplikasi ini sebelumnya dikembangkan oleh salah satu kelompok PPL 2019 kelas C. Aplikasi ini dijadikan sebagai class project PMPL, dimana setiap peserta mata kuliah tersebut diharapkan dapat memberikan ide untuk meningkatkan kualitas dari DIGIPUS dan mengimplementasi ide tersebut.

My Idea

Setelah mencoba aplikasi DIGIPUS, saya menemukan kurangnya informasi seputar pengunduhan, baik untuk user maupun contributor. Setidaknya ada dua kendala yang saya temukan:

Tidak adanya informasi riwayat pengunduhan suatu user.
Tidak adanya informasi jumlah pengunduhan suatu materi.

Kedua kendala tersebut saya jadikan dua ide terpisah untuk peningkatan kualitas aplikasi. Masing-masing ide tersebut saya implementasikan dalam satu sprint (kira-kira 2 minggu). Untuk sprint pertama, saya mengimplementasikan ide saya terkait riwayat pengunduhan.

Riwayat Pengunduhan

Motivasi

Sebenarnya ide ini muncul dari pengalaman pribadi saya yang sering mengunduh berkas yang identik lebih dari sekali karena lupa telah mengunduh berkas tersebut sebelumnya. Menurut saya perlu adanya catatan riawayat pengunduhan sebagai notulensi untk mengingatkan materi apa saja yang pernah diunduh oleh user.

Tujuan

Tujuan utama dari implementasi riwayat pengunduhan adalah menyediakan fasilitas notulensi materi apa saja yang telah diunduh oleh user. Notulensi ini sendiri memiliki dapat digunakan untuk beberapa hal. Antara lain:

Reminder materi mana saja yang telah diunduh.
Sebagai shortcut apabila ingin mengunduh materi yang telah diunduh sebelumnya.

Sekilas poin kedua cukup kontradiktif dengan motivasi saya, namun setelah berpikir, saya sadar bahwa sebuah individu biasanya memiliki lebih dari satu device, sehingga riwayat unduh diharapkan dapat digunakan untuk mengunduh materi yang telah diunduh di satu device pada device lain.

Development

DIGIPUS dikembangkan dalam mata kuliah PMPL, sehingga cukup ditekankan bagaimana melakukan testing pada implementasi. Pengembangan dilakukan dengan konsep Test Driven Development (TDD), dimana perlu didefinisikan testcase yang menjadi tolak ukur akan implementasi yang akan dilakukan. Berdasarkan hal ini, pengembangan fitur pada sprint ini dapat dibagi menjadi dua, yaitu Testing dan Implementation.

Testing

Untuk implementasi pada sprint ini, saya terlebih dahulu perlu mendefinisikan testcase sebagai tolak ukur bagaimana saya mengimplementasikan riwayat pengunduhan pada DIGIPUS. Secara garis besar, hal yang perlu saya tes adalah sebagai berikut:

Penyimpanan kegiatan unduh pada basis data.
Penyajian riwayat unduh suatu user.

Kedua hal tersebut menjadi dasar saya untuk membuat test class, sehingga testcase yang saya definisikan akan terbagi menjadi dua test class. Berikut pendefinisian test class pada aplikasi:

class UserDownloadHistoryTest(TestCase):
# mendefinisikan testcase penyimpanan kegiatan unduhclass DownloadHistoryViewTest(TestCase):
# mendefinisikan testcase penyajian riwayat unduh

Test Setup

Sebelum melakukan testing, terlebih dahulu perlu dilakukan setup awal pada kedua test class untuk mempersiapkan beberapa hal yang diperlukan sebelum melakukan testing. Hal tersebut mencakup:

Memasukkan dummy user untuk memasukkan materi dan mengunduh materi.
Memasukkan materi dummy pada basis data dan membuat download URL materi tersebut.
Proses login.

Testing: Download Activity

Karena sudah ada model class yang mendefinisikan kegiatan unduh, saya hanya perlu menambah fungsionalitas dari model class tersebut. Hal ini berimbas pada tidak adanya negative testing terkait penyimpanan kegiatan unduh, karena sudah didefinisikan sebelumnya.

Selain itu, mengingat sebagian besar user yang mengunduh tidak terdaftar pada basis data, saya memutuskan untuk mengakomodasi riwayat unduh untuk unregistered user menggunakan session. Hal ini berimbas pada tidak adanya testing terkait unauthorized user.

Testing yang saya definisikan terkait kegiatan unduh merupakan kombinasi dari kriteria berikut:

Tipe user (teregistrasi atau tidak).
Jumlah materi yang diunduh (satu atau lebih).
Jumlah user yang mengunduh (satu atau lebih).

Pelaksanaan testing sendiri terdiri dari dua tingkat, yaitu tingkat models dan tingkat views. Perbedaan tingkatan tersebut adalah bagaimana prosedur penyimpanan kegiatan unduh. Untuk memperjelas hal ini, dilampirkan contoh potongan kode test kedua tingkatan.

# tingkat models
def test_multiple_insert_download_statistic_with_user(self):
    DownloadStatistics(materi=self.materi1,   downloader=self.user1_anonim).save()
    num_of_downloads = self.user1_anonim.riwayat_unduh.all().count()
        self.assertEqual(num_of_downloads, 1)
  
    DownloadStatistics(materi=self.materi1, downloader=self.user1_anonim).save()
    num_of_downloads = self.user1_anonim.riwayat_unduh.all().count()
        self.assertEqual(num_of_downloads, 2)# tingkat views
def test_registered_user_multiple_download(self):
    self.client.get(self.download_url)
    num_of_downloads = self.user1_anonim.riwayat_unduh.all().count()
        self.assertEqual(num_of_downloads, 1)    self.client.get(self.download_url)
    num_of_downloads = self.user1_anonim.riwayat_unduh.all().count()
    self.assertEqual(num_of_downloads, 2)

Berdasarkan potongan kode di atas, terlihat testing tingkat models melakukan insertion secara langsung, sementara tingkat views menggunakan URL untuk mengunduh materi dan menyimpan kegiatan unduh.

Testing: Download History

Jika testing kegiatan unduh menguji logic penyimpanan kegiatan unduh, maka proses testing ini menguji bagaimana riwayat unduh pada frontend disajikan. Fokus utama saya adalah memastikan adanya halaman sederhana yang menampilkan riwayat unduh dengan baik. Beberapa hal yang diuji untuk mencapai hal tersebut antara lain:

Memastikan semua riwayat unduh oleh user ditampilkan.
Memastikan riwayat unduh yang ditampilkan tidak tercampur dengan user lain.
Memastikan riwayat unduh ditampilkan secara tersortir.

Secara garis besar, hal tersebut dites dengan melakukan pengecekan pada konten HTML dari halaman riwayat pengunduhan.

Cleanup

Terakhir, diimplementasikan sebuah prosedur teardown untuk membereskan variable atau state yang masih aktif. Dalam test ini, cukup diimplmentasikan prosedur logout pada client.

Implementation

Untuk memenuhi testcase yang dideskripsikan, dilakukan empat macam implementasi. Keempat implementasi tersebut adalah:

Melakukan refactor pada models. Refactor dilakukan dengan menambahkan atribut pengunduh pada model class yang mencatat kegiatan unduh.
Melakukan refactor method download_materi pada views. Method ini menghandle proses pengunduhan, termasuk pencatatan kegiatan pengunduhan tersebut. Disini, saya mengubah prosedur penyimpanan kegiatan pengunduhan dengan menambahkan informasi user yang mengunduh pada informasi yang direcord. Registered user dan unregistered user memiliki cara penyimpanan riwayat yang berbeda, sehingga perlu dilakukan branching untuk menangani penyimpanan riwayat.
Mengimplementasikan frontend untuk menampilkan riwayat unduh. Implementasi dilakukan berdasarkan HTML yang telah ada, mengingat saya sendiri tidak terlalu baik dalam mengembangkan frontend. Selain itu, dilakukan sedikit penambahan selector pada CSS agar dapat digunakan pada HTML yang diimplementasikan.
Mengimplementasikan sebuah view class baru pada views untuk menampilkan riwayat pengunduhan suatu user. View class ini bertujuan untuk menampilkan riwayat tersebut pada suatu HTML. Karena baik registered user dan unregistered user dapat melihat riwayat unduh, maka tidak ada proses otentikasi.

Code Quality

Perlu diingat bahwa pengembangan DIGIPUS merupakan bagian dari kegiatan mata kuliah PMPL, sehingga perlu adanya kontribusi dalam pengembangan kualitas kode. Mengingat banyaknya developer yang sedang mengembangkan DIGIPUS, tidak mungkin saya mengecek kualitas kode apilkasi satu per satu. Untuk sprint ini, saya hanya fokus pada kualitas dari implementasi yang saya lakukan. Berikut beberapa hal yang perlu saya perhatian terkait kualitas implementasi:

Lakukan implementasi hanya untuk memenuhi testcase. Implementasi yang berlebihan akan menyebabkan masalah karena kelebihan implementasi tidak tercover pada testcase.
Pastikan implementasi bebas dari code smell. Code smell yang sering ditemukan pada saat implementasi adalah duplication code dan unused variable.
Pastikan implementasi bebas dari bug. Pada saat melakukan implementasi, bug justru datang dari sisi frontend, sehingga mau tidak mau saya harus mengalokasikan waktu tambahan untuk mempelajari frontend.

Hasil implementasi telah diuji pada SonarCube. Berikut dilampirkan hasil pengujian terhadap implementasi yang dilakukan.

Hasil Pengujian *SonarCube pada Implementasi Riwayat Unduh*

Seperti yang dilihat, implementasi yang dilakukan bebas dari bug dan code smell. Selain itu, implementasi memiliki code coverage 100%, yang artinya implementasi dilakukan hanya untuk memenuhi testcase yang didefinisikan.

Terlihat juga bahwa terdapat duplikasi sebanyak 4.9%. Hal ini terjadi karena saya harus melakukan pull dari branch master untuk menghindarkan conflict pada saat merge. Setelah melihat ini, saya menyadari bahwa secara keseluruhan, kualitas kode DIGIPUS masih kurang baik. Sebenarnya saya kurang menyukai hal tersebut, namun saya sudah berkomitmen untuk tidak menyentuh bagian kode diluar scope kerja saya untuk menghindari conflict.

Lesson Learnt

Aplikasi DIGIPUS menyatukan proses bisnis pada views. Saya belajar bahwa desain seperti ini menyulitkan saya untuk mendefinisikan testcase yang menguji output dari proses bisnis. Sebagai contoh, saya terpaksa mengecek apakah riwayat unduh sudah tersortir atau tidak pada frontend. Menurut saya, alangkah baiknya bila proses bisnis tersebut dapat dipisah dari views. Ide ini sedang dikerjakan oleh salah satu peserta PMPL semester ini. Saya berharap dia tetap sehat selalu, karena dengan jumlah kode yang banyak, pemisahan proses bisnis sangat berat untuk dilakukan dalam satu sprint.