[PMPL Sprint 2 Reflexion] Implementasi Download Count Material DIGIPUS
Introduction
On The Last Sprint…
Pada sprint sebelumnya, telah dilakukan beberapa implementasi yang dilakukan pada aplikasi DIGIPUS. Mulai dari implementasi fitur baru sampai proses refactor basis kode yang sudah ada. Saya sendiri mengimplementasikan fitur download history user agar pengguna dapat mengetahui materi apa saja yang telah diunduh sebelumnya.
New DIGIPUS Codebase: Service Layer
Hal yang perlu saya perhatikan pada aplikasi DIGIPUS setelah sprint 1 adalah basis kode dari DIGIPUS. Teman sekelas saya, yaitu Adrika Novrialdi telah melakukan refactor dengan mengekstrak logic pada views untuk mengimplementasikan satu layer baru bernama service layer. Layer ini berisi proses bisnis yang diperlukan oleh backend. Pemisahan tersebut meningkatkan readability dari kode views. Selain itu, menurut saya pemisahan logic akan memudahkan proses testing logic tersebut, mengingat kebanyakan views selalu melakukan render pada akhir proses. Sebagai refrensi, pada sprint 1, saya langsung melakukan pengecekan frontend pada testing untuk mengecek apakah download count pada suatu materi sesuai ekspektasi atau tidak. Padahal, seharusnya terlebih dahulu dilakukan testing apakah context data download count dari views sudah sesuai ekspektasi atau tidak, baru dapat melakukan testing pada frontend.
This Sprint’s Idea
Seperti yang sudah saya jelaskan pada tulisan saya sebelumnya, pada proyek kelas ini saya mengimplementasikan dua ide, yaitu riwayat pengunduhan suatu user dan informasi jumlah pengunduhan suatu materi. Setelah mengimplementasi riwayat pengunduhan pada sprint 1, saya akan mencoba mengimplementasikan informasi jumlah pengunduhan suatu materi pada sprint ini.
Download Count
Motivation
Fitur ini terinspirasi dari observasi dan pengalaman saya ketika memilih aplikasi atau dokumen dijital untuk diunduh. Saya melihat ada beberapa hal yang menjadi pertimbangan pengguna gadget untuk mengunduh sesuatu. Salah satu hal tersebut adalah jumlah pengunduhan pada aplikasi atau dokumen dijital tersebut. Semakin banyak jumlah pengunduhan, maka semakin besar kemungkinan pengguna gadget untuk mengunduh aplikasi atau dokumen dijital tersebut.
Tujuan
Berangkat dari hasil observasi dan pengalaman saya, tujuan utama implementasi download count adanya menyediakan tolak ukur bagi user sebagai salah satu pertimbangan untuk memilih materi mana yang ingin diunduh. Selain itu, download count juga menjadi tolak ukur terhadap ekspektasi kualitas materi yang ingin diunduh, sehingga user tidak terlalu “kaget” ketika kualitas materi di bawah atau di atas ekspektasi.
Development
Seperti sprint sebelumnya, pengembangan dilakukan dengan konsep Test Driven Development (TDD), sehingga terbagi menjadi dua tahap, yaitu Testing dan Implementation.
Testing
Seperti sprint sebelumnya, saya terlebih dahulu perlu mendefinisikan testcase yang menguji fitur yang ingin diimplementasikan. Testcase ini berperan sebagai tolak ukur bagaimana saya mengimplementasikan download count pada DIGIPUS.
Pada pendefinisian testcase download count, terdapat perbedaan dengan pendefinisian testcase riwayat unduh. Saya tidak mendefinisikan test class baru untuk fitur download count, namun menambahkan testcase fitur download count pada test class DetailMateri. Pendefinisian ini dilakukan dengan pertimbangan bahwa download count merupakan bagian dari informasi detil materi, sehingga saya memutuskan untuk memasukkan download count sebagai bagian dari detil materi.
Test Setup
Karena menambahkan testcase pada test class yang sudah ada, sebenarnya tidak perlu melakukan setup ataupun teardown lagi. Namun demikian, saya memerlukan dua materi dalam proses testing, padahal pada setup DetailMateri hanya diinisiasi satu obyek materi. Untuk memenuhi kebutuhan testing, saya perlu melakukan inisiasi materi kedua pada setup.
Test Design
Meningat logic aplikasi sudah memiliki layer terpisah, saya dapat melakukan test khusus pada layer tersebut. Sejatinya saya berencana melakukan testing pada tiga layer, yaitu pada models, logic, dan frontend. Namun ternyata download count pada level model telah ditesting pada implementasi sebelumnya, sehingga saya hanya melakukan testing pada logic dan frontend. Untuk memperjelas perbedaan kedua level tersebut, dilampirkan contoh testcase pengujian download count materi yang diunduh sekali pada kedua level.
# testcase level logic
def test_download_count_when_single_download(self):
self.client.get(self.download_url1)
context = {}
DetailMateriService.init_materi_download_count(context, self.materi1)
self.assertEqual(context['materi_download_count'], 1)# testcase level frontend
def test_download_count_displayed_on_template_when_single_download(self):
self.client.get(self.download_url1) response = self.client.get(self.url)
html = response.content.decode("utf-8")
self.check_materi_info_in_html(self.dcount_info_name, 1, html)
Untuk hal yang saya uji, kedua level akan menguji beberapa hal berikut:
- Testing download count suatu materi ketika belum diunduh.
- Testing download count suatu materi ketika materi diunduh sekali.
- Testing download count suatu materi ketika diunduh beberapa kali.
- Testing perbandingan download count antara dua materi berbeda dengan jumlah unduh yang juga berbeda.
Perbedaan testing pada kedua level berada pada resouce yang diuji. Level logic menguji context untuk mengetahui download count, sementara level frontend menguji konten HTML untuk mengetahui download count. Khusus pada level logic, dilakukan testing tambahan untuk:
- Menguji apakah context download count berhasil ditambahkan.
- Menguji apakah tipe data download count berupa integer atau tidak.
Implementation
Untuk memenuhi testcase yang dideskripsikan, dilakukan tiga macam implementasi. Ketiga implementasi tersebut adalah:
- Implementasi service untuk menambahkan download count pada context. Download count suatu materi didapat melalui build-in method .count() milik Django.
- Implementasi penggunaan service download count pada views. Penggunaan dilakukan dengan menggunakan method service download count dengan parameter context yang sedang dibuat.
- Implementasi penyajian download count pada frontend. Download count pada suatu materi akan ditampilkan di dalam kumpulan baris yang berisi detil informasi materi.
Code Quality
Sama seperti sprint sebelumnya, pada sprint ini saya perlu memperhatikankualitas dari implementasi yang saya lakukan. Hal yang saya perhatikan pada implementasi saya masih seputar implementasi yang hanya memenuhi testcase, implementasi bebas code smell, dan implementasi bebas bug.
Hasil implementasi kembali diuji pada SonarCube. Berikut dilampirkan hasil pengujian terhadap implementasi yang dilakukan.
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 0%. Hal ini terjadi karena pada saatmelakukan pull dari branch master, tidak ada conflict yang menyebabkan duplikasi kode.
Dari sini saya merasakan pengingkatan kualitas setelah logic backend dipisah menjadi layer tersendiri. Selain mempermudah testing pada bagian logic, pemisahan juga mengurangi resiko terjadinya merge conflict.
Lesson Learnt
Saya belajar pentingnya memisahkan setiap layer aplikasi semodular mungkin. Hal ini akan mempermudah proses testing pada logic. Lebih lanjut lagi, saya pun mulai merasakan pentingnya isu quality assurance seperti pemisahan layer ini. Isu quality assurance tidak menambah fungsionalitas apapun, namun jika isu tersebut ditangani, akan mempermudah proses implementasi yang akan datang.