Ngobrolin Testing
Ringkasan Episode
Bantu KoreksiRiza, Ivan, dan Eka membahas testing — atau pengujian, istilah yang diakui masih terasa asing di telinga. Definisinya sederhana: kita punya ekspektasi, lalu memastikan hasilnya cocok. Tapi urgensinya baru terasa ketika kode terus bertambah dan dipakai banyak orang; kesalahan kecil pada modul yang dipakai jutaan aplikasi bisa merusak semuanya sekaligus, dan mengecek satu per satu secara manual sebelum tiap rilis jelas tidak sanggup mengejar. Nilai testing yang paling ditekankan justru bukan soal menangkap bug. Menulis test memaksa kita berpikir jernih tentang apa yang ingin dicapai — semacam to-do list sebelum ngoding, dan dokumentasi setelahnya untuk diri sendiri enam bulan kemudian atau untuk rekan kerja yang belum tahu maksud kodenya. Ada juga cerita bahwa test bisa memperbaiki desain sistem: kalau test untuk satu tampilan jadi kebanyakan, artinya tanggung jawab elemen itu terlalu besar dan perlu dipecah. Bagian paling jujur di episode ini adalah pengakuan bahwa waktu yang dihemat dengan melewatkan testing itu sia-sia. Ivan bercerita tentang plugin WordPress yang harus jalan di beberapa versi PHP dan WordPress sekaligus; tanpa test otomatis, setiap rilis berarti tiga sampai empat jam permutasi manual, dan satu fatal error berarti mengulang dari awal — sampai akhirnya burnout. Sisanya membahas jenjang unit, integration dan end-to-end testing, mocking layanan pihak ketiga dengan MSW, storybook, Playwright dan Cypress, sampai git hooks dan CI agar kode yang belum lulus tidak pernah sampai ke production.
Poin-poin Utama
- •Nilai terbesar testing bukan menangkap bug melainkan memaksa berpikir jernih: test jadi to-do list sebelum ngoding dan dokumentasi setelahnya, termasuk saat kita membaca repo orang lain dan readme-nya kurang lengkap
- •Testing bisa memperbaiki desain sistem — kalau test untuk satu tampilan jadi kebanyakan, itu tanda tanggung jawab elemen tersebut terlalu besar dan perlu dipecah
- •Waktu yang dihemat dengan melewatkan testing itu sia-sia: plugin WordPress yang harus jalan di banyak permutasi versi PHP dan WordPress butuh 3-4 jam pengecekan manual setiap rilis, dan satu fatal error berarti mengulang semuanya
- •Jenjangnya naik dari static analysis di dasar, lalu unit testing, integration testing, sampai end-to-end testing: semakin ke atas semakin dekat ke user tapi semakin mahal dijalankan, sementara unit test justru paling murah dijalankan tapi paling besar effort menulisnya
- •Panggilan ke layanan pihak ketiga seperti payment gateway harus di-mock — bukan hanya agar test tidak menembus rate limit atau menagih biaya, tapi karena error code-nya jauh lebih banyak daripada skenario sukses dan semuanya perlu ditangani
- •Automatic testing sudah bergeser jadi tugas developer, bukan hanya divisi QA; QA manusia menguji dari sudut pandang user, sementara manusia memang tidak didesain untuk pekerjaan repetitif berskala besar
- •Gabungkan testing dengan alur kerja lewat git hooks dan CI supaya kode yang belum lulus tidak pernah di-commit apalagi di-deploy — tapi perhatikan juga soal billing, karena jam GitHub Action gratisan ada batasnya
Hai hai hai, kita tunggu lagi.
Semuanya.
Selamat Hari Selasa.
Selamat Hari Selasa, hari selasa adalah waktunya?
Waktunya ngobrolin web.
Ngobrolin web. Masih bareng kita bertiga bersama saya Riza.
Ada Ivan dan ada Eka juga.
Dari GDE untuk teknologi web Indonesia.
Web Indonesia.
Gimana kabarnya teman-teman?
Kita masih butuh GDE web selanjutnya.
Kita masih butuh GDE web.
Ada, ada apa?
Ada ini, ada apa?
Bocoran-bocoran dari Mas Denang kemarin.
Tapi kita nanti bicara kan di belakang layar saja.
Malah bikin penasaran yang lain.
Siapa tahu tahun depan ada empat kolom di sini?
Amin, mudah-mudahan.
Bakal ada empat, lima dan seterusnya.
Ada Dita yang baru ketemu.
Terakhir hari...
Semarang.
Ini, Pak Makasar.
Hari ini masih ketemu kita.
Diajak makan-makan, tempatnya kemana-mana ya.
Contoh Makasar.
Ini apa nih?
Kotak-kotak ini.
Unicode.
Lihat transkrip lengkap (2198 segmen lagi)
Kapan-kapan kita bahas karakter Unicode?
Detail kali ya.
Mungkin di sini, dia pasang Unicode.
Jadi nggak bisa muncul tuh.
Pons, kita bahas Pons di tahun lalu.
Ini yang lalu kan?
Makasar kemarin Defece-nya mantap.
Keren banget.
Sampai over kapasitas ya.
Tapi keren lah, mantap sekali.
Tepok juga mantap.
Selamat buat teman-teman GDG.
Yang mengadakan Defece.
Sukses ya.
Sudah selesai semua ya Indonesia.
Kalian talk.
Terakhir Makasar, Depok, Bandung, dan teman-temannya.
Minggu lalu.
Dan malam hari ini kita akan...
Menyapa-nyapa dulu.
Ada Septian, ada Dito.
Ada Thams.
Ada siapa nih?
Saiful Rahman. Halo-halo.
Dan seperti yang ada di judul.
Kita akan membahas tentang...
Testing.
Testing ini adalah...
Salah satu, dua, tiga.
Bahasa Indonesia apa ya?
Pengujian ya, pengujian.
Gatau apa ya resminya? Betul gitu.
Pengujian.
Cacok kan?
Cuman agak masih asing ya.
Test runner apa dong?
Ujian sambil lari.
Pengujian.
Salah, test runner itu pengujian.
Boleh, boleh, boleh.
Ada...
Topik tentang testing ini adalah...
Topik yang sangat wise ya.
Seperti...
Mas Dana waktu...
Saya mau ke Makasar...
Dia bilang pesannya adalah...
Eating wisely.
Berlebihan.
Karena berbahaya.
Dan ada Dina juga...
Ada Power Ranger.
Power Ranger. Ini Ranger apa?
Ranger Merah.
Dari ikonnya Ranger Merah. Jason ya?
Jason.
Jason Srinivai.
Nama panjangnya.
Oke, oke.
Testing.
Ini kita ngelantar ke mana-mana ya.
Testing.
Apa itu testing?
Siapa yang bisa menjelaskan tentang testing?
Testing. Testing itu kan kita...
Kode kita banyak ya.
Nah, terus kita punya...
Kita nggak tahu nih...
Bakal selalu berjalan dengan baik atau nggak.
Terutama nanti kalau udah diubah...
Berkali-kali.
Atau mungkin digunakan di komponen...
Atau fungsi atau modul yang berbeda.
Nah, jadi intinya nggak tahu ini...
Definisi lebihnya atau nggak.
Saya coba.
Punya ekspetasi.
Terus kita matching dengan...
Hasilnya cocok nggak? Sesuai nggak dengan...
Atau ekspetasi kita.
Itu harus selalu sesuai.
Kalau tambahan dari saya...
Kivan, gimana?
Testing itu bagian dari kualitas...
Assurance.
Assurance itu artinya memastikan.
QA.
Bagaimana memastikan kalau kode kita itu...
Sorry, kalau aplikasi kita itu...
Tetap berjalan...
Sesuai dengan...
Requirement.
Harapan.
Harapan dan sesuai dengan...
Yang diplankan, yang dicitakan.
Jadi...
Kalau inputnya A...
Dan diharapkan...
Diharapkan hasilnya B...
Harus...
Inputnya A tetap B.
Jadi jangan di input A jadi C.
Jadi memastikan itu.
Mungkin kelihatannya sepele.
Keliatannya sepele.
Misalnya kalau kita bikin fungsi...
Jumlah.
A tambah B menjadi C.
Keliatannya sepele.
Tapi kalau misalnya kita sudah...
Memikirkan scale.
Skalabilitas.
Kode kita terus bertambah.
Apalagi kalau kita manage...
Open source...
Manage project...
Open source atau project enterprise.
Atau project...
Skala kecil tapi dipakai...
Jutaan aplikasi.
Jutaan aplikasi.
Bayangkan kalau kita...
Kesalahan sedikit...
Mengubah kodanya...
Jutaan aplikasi bisa rusak.
Makanya butuh quality assurance.
Dan karena kita...
Developnya secara kontinu, tentu kita...
Masa kita ngelakukannya...
Capek juga ya...
Ngetes satu-satu.
Mau deploy atau memperbarui...
Aplikasi kita, kita harus cek satu-satu.
Bayangkan kalau...
Kalau aplikasi itu besar...
Kita harus cek satu-satu semua.
Jadi...
Butuh namanya...
Testing.
Bagi naik quality assurance.
Juga ada yang disebut dengan TDD.
Test Driven Development.
Dimana kalau kita...
Mau nondevelop sesuatu...
Buat dulu testnya.
Buat dulu scenario-nya.
Jadi dari tiket...
Scenario-nya apa?
Apa yang diharapkan?
Pastinya baru buat kodenya.
Kalau saya dulu, sukanya...
BDD, Bug Driven Development.
Asal ada bug, perbaiki.
Asal ada bug, perbaiki.
Ada bug, perbaiki.
Ya.
Ngomongin tentang bugs, juga kadang-kadang...
Ya, kita kan nggak bisa...
Selalu dalam kondisi ideal.
Misalkan katakanlah, "Wah, dikejar deadline..."
"Kita harus bikin aplikasi tapi tanpa tes."
Awalnya gitu kan.
Tiba-tiba begitu di tes...
"Eh, ternyata ada bugs."
Untuk memastikan bugs ini tidak muncul lagi...
Kita bisa bikin tes dari situ.
"Oh, pastiin ini tidak akan muncul."
Jadi ketika nanti kita perbaiki...
Terus ada bugs kedua...
Kadang-kadang kan sering jadian ya...
Bugs pertama muncul, kita perbaiki.
Bugs yang pertama...
Balik lagi.
Jadi salah satu fungsinya tes adalah...
Untuk memastikan bahwa...
Bugs pertama itu akan tetap di...
Tetap dihandle.
Tidak muncul lagi.
Kalau pun ada error, dia akan ketahuan.
Dan artinya...
Implementasi untuk menyelesaikan bugs kedua...
Ada yang keliru.
Karena bugs pertamanya jadi muncul lagi.
Berarti itu kombinasi ya...
BDD dan TDD.
Back-driven dan test-driven.
Ada satu hal yang saya dapatkan dari Mas Deta.
Waktu di DevFest Depok kemarin...
Dia bercerita tentang testing.
Bagaimana testing itu...
Bisa memperbaiki konsep desain sistemnya...
Aplikasi kita.
Jadi uniknya di situ.
Gimana-gimana?
Itu Mas Riza dah balik.
Saya ulang sedikit biar Mas Riza bisa nanti.
Jadi waktu itu Mas...
Oke, bentar.
Mistake-nya habis kali.
Baterai habis.
Belum dicolok.
Cek, cek, cek.
Sudah.
Jadi ada satu hal yang saya pelajari dari Mas Deta.
Waktu di DevFest Depok kemarin itu...
Bagaimana testing itu bisa...
Memperbaiki konsep desain sistemnya kita.
Dengan melakukan tes.
Jadi contohnya...
Kalau misalnya sebuah tampilan...
Hanya tampilan Dasbo.
Dengan tesnya kita.
Kalau tesnya kebanyakan...
Artinya desain sistem kita itu...
Ada yang salah.
Ada yang kurang benar.
Karena tesnya jadi kebanyakan.
Jadi bagian...
Responsibility dari UI elemen kita...
Terlalu banyak.
Akhirnya harus dipecah-pecah.
Mana yang controller.
Mana yang...
Apa yang disebutnya?
Satu controller, satu lagi apa?
-Model. -Model misalnya.
Controller dan model.
Jadi mana yang hanya ngurus data, mana yang ngurus...
Bagian input-outputnya.
-Pesentasi. -Pesentasinya.
Jadi kalau dipisah...
Sehingga...
Testnya itu bisa lebih...
Lebih spesifik terhadap...
Terhadap elemen tertentu.
Dan...
Hasilnya desain sistemnya kita jadi lebih baik.
Sehingga kalau nge-debug...
Itu bisa langsung tepat...
Tepat...
Tepat sasaran.
Dan juga testing scenario-nya...
Itu jadi lebih cepat karena...
Scope-nya lebih kecil.
Seperti itu.
Jadi kalau markup, ya fokus di markup.
Terus kalau misalnya ada logic-nya kayak...
Reusable function kayak buat...
Memproses string, number gitu...
Kalkulasi itu dipisah ya.
Di unit testing sendiri.
Makanya ada unit testing, terus kemudian naik...
Integration testing.
Naik lagi end-to-end testing.
Ada...
Kalau saya sukanya... -Accept end testing.
Assertance testing.
Visual regression testing.
Ada lagi performance testing.
Isinya testing semua.
Kodanya dikit.
Ngomongin soal tadi ya...
Tididi ya, test development ini kan...
Sesuatu yang...
Kadang kalau baru mulai agak...
Sulit ya, karena testing aja...
Baru, terus tiba-tiba kita harus...
Nulis testing duluan nggak kebayang gitu kan.
Tapi di luar itu...
Mau testing duluan...
Atau testing belakangan...
Intinya adalah yang penting harus ada testing.
Dan benar sekali tadi...
Yang disampaikan Ivan bahwa...
Ketika kita menulis testing, itu sebenarnya...
Kita sedang mendesain.
Mendesain aplikasi kita atau mendesain...
API untuk aplikasi kita.
Di sini ada artikel yang menarik nih.
Tentang... Dia sih bahasannya tentang TDD ya.
Tapi ini berlaku juga untuk testing.
Jadi testing itu bisa...
Memaksa kita untuk berpikir.
Secara jernih.
Apa yang ingin kita capai.
Bahkan...
Nggak jarang kalau saya bikin...
Aplikasi terus...
Ada testingnya duluan gitu ya.
Atau TDD gitu ya.
Itu jadi kayak tuduh, kayak tuduh tulis.
Pertama, saya pengen halaman ini...
Ada...
Titlenya ada headernya.
Kemudian ada descriptionnya.
Kemudian ada formnya, formnya isinya...
Ada username, ada password, ada login form dan lain-lain.
Itu kayak...
Tuduh aja gitu, tuduh tulis.
Jadi itu...
Menjadi kerangka berpikir aja sebenarnya ya.
Testing itu bukan hanya sekedar untuk...
Ngecek apakah aplikasi kita jalan...
Oke atau enggak.
Tapi lebih ke bagaimana cara kita berpikir.
Dan ke depannya itu...
Bisa jadi dokumentasi ya.
Sama-sama, itu sebelum kita bikin...
Itu tuduh.
Setelah kita bikin, 6 bulan kemudian kita...
Udah ngerjain hal yang lain, kita pasti lupa.
Kemungkinan besar kita lupa.
Atau teman kerja kita belum tahu.
Itu kan bisa kayak...
Nerjemahin kodingan yang tadinya...
Nggak tahu maksudnya apa.
Tapi ini ada bisnis goalnya kan.
Maksudnya minimal ada...
Picking header atau ini harus menyumbahkan.
Blablabla. Jadi tuduh dan nantinya...
Sebagai dokumentasi ya.
Oh iya. Nggak jarang kadang-kadang...
Kalau misalkan kita lihat...
Atau apa, saya lihat di...
Sebuah repo gitu kan.
Ini gimana cara pakai library-nya ya.
Lihat di readme mungkin kurang lengkap gitu kan.
Tapi ada folder test nih.
Kita lihat aja di situ.
Bagaimana cara penggunaan itu juga salah satu...
Point yang bagus sekali ya.
Jadi test itu selain sebagai...
Kerangkap berpikir.
Kemudian sebagai...
Pengujian untuk aplikasi kita.
Dan juga sebagai dokumentasi.
Di sini...
Benefit kedua menurut...
Si JR Sinclair ini.
Adalah...
Kalau kita nge-debug, itu lebih mudah.
Karena kita bisa tahu bahwa...
Kalau kita nge-debug sesuatu...
Eh, testingnya error nih. Oh berarti ini masih salah.
Dan seterusnya.
Dan yang ketiga ini...
Objektif, subjektif ya.
Apakah lebih...
Menyenangkan? Bisa jadi.
Kita bikin testing duluan, kita lihat merah gitu kan.
Begitu jadi hijau kan seneng gitu kan.
Jadi ada achievement gitu kan.
Kebahagiaan tersendiri gitu.
Jadi ya...
Lumayan... Jadi kayak apa ya?
Kayak gamification jadinya juga ya.
Betul.
Kamu di TDD ini, saya ada...
Sering menemukan...
Pendapat yang anti-pattern untuk TDD.
Itu...
Pertama, nulis sebuah...
Bahasanya...
Flow dari...
Dari...
Pengerjaannya lebih lama.
Karena harus nulis test, harus nulis code.
Kedua...
Ya elah...
Kodenya yang dirubah sedikit, nunggu testnya lama banget.
Gitu kan.
Oh, test running-nya lama ya?
Karena sudah terlalu besar.
Test runner-nya, misalnya...
Let's say...
Mungkin kalian develop...
Chromium browser, maybe ya.
Coba aja menjalani test Chromium browser.
Kalau bisa di komputer kalian, gitu kan.
Jadi...
Yang dirubah cuma satu line.
Kita tahu satu line itu gak bakalan...
Bikin rusak, gitu kan.
Tapi...
Menjalani testnya itu harus 6 jam.
Misalnya...
Tiba-ibas.
Nah, itu kan ibaratnya...
Sebuah...
Pendapat yang anti-pattern. Ada yang kayak...
Ya udahlah, develop aja cepat.
Kalau ada bug, nanti diperbaiki, gitu kan.
Ada juga yang anti-pattern seperti itu.
Gimana nih, menurut...
Mas dan mbak-mbak.
Cuma realistis sih ya.
Emang... Apa?
Terutama kalau yang freelance...
Lombok dong, kalau ngabisin...
Waktu banyak buat ngetest.
Karena kalau misalnya... Apa?
Nulis test, kalau jumlah jamnya...
Dicharge ke klien...
Mungkin ada kompetitor...
Yang nggak pake testing.
Cuma kalau klien...
Bukan coder, bukan programmer, kan...
Nggak bisa expect untuk apresiate...
Hal-hal yang tadi semua kita bilang kan.
Karena sulit jualan...
Kalau kita bilang...
Jualan dengan harga sekian...
Karena kita ada testnya, loh.
Jadi lebih lama, atau jadi lebih mahal, gitu ya.
Padahal toko sebelah...
Tanpa testing.
Kualitasnya dianggap sama, bisa lebih cepat.
Cuma itu... Mungkin...
Nah, jujur...
Sejak aku jadi... Apa?
Developer full-time, nggak...
Belum pernah freelance yang charge by the hour sih.
Jadi, belum pernah ngerasain...
Dilema yang kayak gitu. Cuma kalau...
Yang dipraktekin sekarang, mah...
Ya... Apa ya? Nah, go kompromi sih.
Jadi kan...
Ada filsafatnya juga kan, tuh. Apa?
Testing, terutama yang sering dipost oleh...
Can see dots, kan.
Gak usah banyak-banyak.
Tapi integration testnya lebih banyak.
Jadi ini kan sebetulnya kayak...
Pick your battle. Jadi...
Gak harus semua hal yang kecil-kecil banget...
Kita tulis unit testnya...
Satu persatu. Kalau memang...
Terutama kalau ada...
Itu waktu.
Atau satu flow. Misalnya...
Bisa login. Ya kan?
Itu satu flow, kan. Bisa masukin email.
Password. Pencet button login.
Apa yang terjadi. Ya, kayak...
Itu... Gimanapun ya...
Ya, nulis itu kan tetap makan waktu dan...
Tenaga ya. Jadi itu gimana kita...
Kompromi aja sih.
Sulit di judge one size fits all.
Oke.
Sebelum saya menjawab...
Ini ada pertanyaan bagus.
Testing website itu key A ya?
Divisinya sebutannya key A.
Sebenarnya gini...
Ada sedikit pergeseran ya.
Kalau dulu kan divisinya berbeda ya.
Yang benar-benar yang testing ya...
Memang divisi QA gitu kan.
Software quality assurance.
Atau semacamnya.
Tapi semakin kesini...
Untuk automatic testing, terutama yang...
Kayak unit test, integration test.
Atau end-to-end testing.
Itu sudah...
Secara tidak langsung masuk ke rolnya...
Developer sekarang. Masing-masing developer.
Developer itu sekarang udah...
Nambah tugasnya. Selain harus bikin...
Implementasi code, juga harus...
Bisa testing. Testingnya...
Tidak sekomprehensif...
Testing team QA ya. Kalau QA kan...
Tulisnya beda lagi ya. Ada Katalon Studio...
Katalon biasanya.
Yang drag and drop. Terus dia bisa ngecek...
Apakah skenario-nya lebih lengkap...
Daripada yang kita tulis.
Jadi agak sedikit berbeda.
Dan itu juga sebenarnya...
Mau wakili end-to-end kan ya? Apa?
Firefox playwright.
Di Firefox kan ada yang drag and drop juga...
Jaman dulu itu dia membuat automation.
Selenium?
Bukan.
Bukan.
Ya mungkin...
Mungkin untuk apa ya...
Untuk perusahaan-perusahaan yang sudah besar...
Pasti ada team QA-nya sendiri.
Ya jadi satu team.
Tapi...
Kalau developer sekarang sih kayaknya...
Harus ya. Harus bisa testing ya.
Itu.
Minimal...
Minimal misalnya ada orang QA yang...
Menjalankan end-to-end dengan...
Canggih banget ada suite... Apa?
Test suite-nya sendiri. Nah kita...
Di sisi lain kita bikin unit testing...
Sedikit aja memastikan misalnya...
Komponennya terload dengan benar.
Udah gitu. Apa?
Paling minimal mulai dari situ. Ya nanti kalau ada...
Waktu dan tenaga lebih bisa dikembangin.
Funksinya jalan.
Atau komponennya terload.
Dirender dengan normal.
Ya.
Jadi si... Apa? Si division QA ini...
Akan...
Mencoba aplikasi kita dari sisi...
Dari sudut pandang user.
Ya.
Kalau kita ya dari sudut pandang kita.
Developer. Untuk... Ya itu tadi apa?
Kerangka berfikir aja.
Jadi di ibaratkan sebagai...
Kerangka berfikir.
Ada... Ada pernyataan...
Ada satu dari Mas Deta...
Waktu di presentasinya itu.
Testing itu adalah user pertama kita.
Nah.
Jadi user pertama kita itu adalah...
Testing. -Test runner-nya?
Iya. -Kode testing-nya?
Iya, iya, iya.
Ya, kalau menjawab yang tadi ya.
Jadi...
Memang kerjaan kita nambah ya.
Kita harus bikin testing.
Harus bikin implementasinya.
Kalau nanti ada perubahan.
Kita harus ubah lagi testingnya.
Jadi kan kode testing kita kan
di otomasi dengan kode kan.
Kode-nya ini kan juga harus dimaintain kan.
Ditambahkan atau dikurangin.
Yang biasanya sih bertambah ya.
Bertambah terus seiring dengan...
Apa, skenario-skenario yang bertambah gitu.
Jadi memang...
Pekerjaan yang...
Menambah pekerjaan lah intinya.
Cuman...
Saya...
Gak tahu ya temen-temen ya.
Kalau saya sudah mengalami dan saya percaya bahwa
testing akan menyelamatkan kita.
Daripada misalkan gini.
Projeknya 3 bulan.
Terus gara-gara bug fixing jadi 6 bulan.
Akan lebih baik, kita udah planning dari awal 6 bulan.
Berserta tes gitu.
Jadi tidak stres daripada fixing bugs.
Fixing bugs itu...
Lebih makan waktu.
Melelahkan sekali secara mental.
Saya mau berbagi pengalaman.
Nyata.
Jadi sebuah projek.
Kita jalankan, kita perbaiki.
Di situ saya enterprise sudah banyak.
Banyak banget bagian-bagiannya.
Kita perbaiki.
Ini bagian visual aja ya.
Gak usah sampai unit-unit testing.
Atau feature-feature.
Tapi hanya visualnya aja, CSS bahasanya.
Kita perbaiki CSS.
Kita perbaiki karena ada masalah
viewport.
Di viewport tertentu masalah atau di browser tertentu masalah.
Kita perbaiki.
Udah di tes live.
Tetapi suatu saat, balik lagi, kenapa?
Karena di bagian lain ternyata
pakai komponen yang sama tetapi malah
jadi overlap.
Dan itu tidak ketahuan.
Tidak ketahuan waktu di tes.
Oleh manusia.
Karena manusianya
nggak ngecek ke bagian lain.
Karena kita tahu
ini page yang masalah,
ini page yang kita perbaiki.
Tetapi page yang lain tidak di tes.
Kliennya jadi marah.
Kenapa setiap kali ada
kenapa urusan visual
ini nggak beres-beres sih?
Akhirnya jadi makan hati.
Jadi kayak
vicious cycle.
Karena kita nggak punya
kita nggak punya
kerangka testing waktu itu.
Ya itu yang
lebih berbahaya kan. Maksudnya
capek, capek
di mental gitu kan.
Yang membuat moral tim
turun yang akibatnya bisa
panjang tuh. Bisa resign,
bisa apa, macem-macem.
Karena kerjaannya jadi itu-itu aja.
Iya, kerjaannya jadi membosankan
dan melelahkan.
Jadi akan lebih baik kalau
ya udah, mendingan
kerjaannya banyak nggak apa-apa, tapi
lumayan menyenangkan gitu kan. Maksudnya
nggak bolak-balik
mengerjakan hal yang sama berulang-ulang.
Itu sih kalau
dari sekarang.
- Menarik.
- Terus kita bahas apa lagi nih?
Tadi sempat dibahas sedikit
tentang ini ya. - Genis-genis tes kali ya?
- Genis-genis tes ya. - Genis-genis tes kali.
Belum. - Bentar-bentar, sebelum.
Ini dia. - Nah.
- Kopilah dunia.
- Bentuknya, bentuknya kayak piala.
- Oh, bentuknya.
- Nah, itu.
Ya, ini opini juga sebetulnya sih.
Cuma ini rekomendasi yang
bagus sih.
Jadi paling bawah tuh dasarnya
itu bahkan nggak
bukan exactly automatic
testing ya, cuma static analysis.
Itu kita pakai TypeScript,
jadi sebelum dijalankan pun kita udah
mencegah bug-bug yang
udah bisa dideteksi, kayak misalnya
salah jenis harusnya number
jadi string, salah ketik,
field-nya ilang, nama field-nya berubah.
Itu kan hal-hal yang, ya udah kita
nggak usah buang waktu ngejalanin apa-apa
kalau itu bisa ditangkepkan.
Nah, terus unit testing itu tadi yang perbagian-bagian
entah itu fungsi
kayak reusable function,
permetodnya ditest sendiri,
yang tadi dibahas Ivan itu
perkomponen atau markup dibahas sendiri.
Nah, integration itu
satu section lah, gabungan dari
beberapa, misalnya dalam satu
komponen kan ada markup-nya,
ada styling-nya,
ada function-nya,
ada logic-nya yang pure function, nah terakhir
end-to-end tuh, yang dari awal sampai akhir
serangkaian dari perspektif
user, misalnya user mau sign up,
user mau create post, dan
lain-lain. Nah, ini
bentuknya itu yang
direkomendasikan kalau
menurut perspektif
can see dots ini sebagai
full stack web dev itu
terbanyak di integration katanya.
Setuju nggak? Ini kan
tetap opini ya.
Ya, jangan lupakan juga
semakin ke atas
dari static unit
integration end-to-end, itu
semakin berat jalaninnya.
Semakin mendekati user,
tapi kalau dijalankan semakin berat.
Karena ada automated-nya kan, kalau end-to-end kan,
dia seolah-olah membuka browser sendiri,
terus dia click, dia...
Paling mahal lah ya, mahal.
Bukan selalu dalam arti
finansial, tapi mahal tenaga lah, mahal
resource. Ya, jadi resource-nya
lebih banyak, bekerjanya lebih sibuk
lah laptop kita ya.
Kalau static praktik,
unit testing ringan, static
analysis tuh hampir gratis lah ya,
kita sekarang kalau pakai VS code
kan udah include semua.
Bisa langsung disave,
langsung otomatis nge-format,
ngasih tau wording sendiri.
Kalau kita salah, ESLint juga udah
ngasih opsi buat benerin,
ngasih rekomendasi.
Tapi di lain sisi,
kalau end-to-end itu paling mahal, unit test
atau static itu paling murah,
kalau kita nulis unit test,
itu effort-nya paling besar,
karena kita ngetes-nya banyak.
Lebih banyak
daripada yang end-to-end. Kalau end-to-end misalkan
kita ngetes form logic,
form logic ya, click
input yang pertama,
masukin username, click input
yang kedua masukin password, click login,
hasilnya, selamat datang
di dashboard, gitu kan.
Kalau unit test, ya kita harus ngetes
masukin username ini.
Ada inputnya, ada button-nya,
ada function buat nge-check jumlahnya, karakternya
udah betul atau nggak.
Betul, sangat banyak gitu. Jadi, effort-nya
akan sangat besar, tapi di sisi
yang lain kalau dijalankan
ya lebih ringan, itu aja sih. Jadi,
kita harus mencari keseimbangan.
Kalau dari Ken C.Dot kan, dia bilangnya integration testing
yang di tengah-tengah lah ya,
nggak terlalu berat, tapi juga
tidak terlalu banyak effort dari sisi
kitanya sebagai developer.
- Yang paling banyak
saya lakukan memang diintegration sih
sebenarnya. Karena
karena saya taunya itu.
- Dulu aslinya
itu terus
dibikin ulang sama
dulu tweet aslinya dia, itu
artikel ini berasal dari tweet
tadinya dia nge-tweet kayak gitu ya, tentang
ide-nya yang masih mentah.
Terus karena banyak yang respon, dikembangin sebagai
artikel. Terus ada ilustratornya
Ekhet, kalau nggak salah yang bikin
secara lebih
proper, bandingkan bedanya
developer dan ilustrator.
- Ini masih pakai flow ya,
belum typescript ya.
- Tahun berapa itu?
2018?
- 2018. - Ya, dulu
masih rebutan.
- Kalau idealisme ya,
mulai dari kodenya sendiri,
sudah
type,
strict type,
ya udah strict.
Terus kemudian
karena strict type-nya, return-nya
pun sudah jelas segala macam, field-nya
sudah jelas, terus naik ke
berarti untuk mendesain unit test-nya
dan scenario-nya dari setiap
functions juga sudah jelas.
Terus naik lagi,
menggabungkan setiap kali
pemanggilan function-function itu
dijadikan sebuah integration.
Disinilah banyak scenario-senario
kan.
scenario, misalnya
it should see blah-blah-blah
it will
get data
like this, shape-nya
shape-nya seperti apa, blah-blah-blah itu sudah
ada di integration.
Terus kemudian jalanin end-to-end
test-nya juga ada scenario kan.
Kalau misalnya login fail, login
success, login
tiga kali harusnya
lihat
contohnya
lihat mesej apakah kamu
lupa password, tunjukin masa
something. Forgot password.
Jadi, kalau
kembali lagi, kalau misalnya kita
sudah bisa desain dari
dari bawah sampai ke atas
untuk sebuah
functionality, tentu kode
kita pun, itu sudah kita
pecah-pecah.
Ya, sudah kita pecah-pecah
sesuai dengan
responsibilty dari setiap bagian.
Itu akhirnya sudah
sebuah desain sistem kan. Sudah sebuah
desain sistem dari yang untuk
kita, asetectur dari
kodenya kita itu.
Itu
untuk
itu akan meningkatkan yang disebut dengan
maintainability.
Kode kita jadi gampang di maintain.
Kode kita jadi
kalau dengan static analysis
kan, kita wajib tuh bikin
bikin
JSdoc atau
dokumen-dokumennya itu kan, sudah harus
bisa diwajib kan.
Jadi, documentability-nya juga
dokumentasinya juga jadi jelas.
Dari testing scenario-nya juga
jadi jelas.
Ingat, kalau dari
biasanya kalau membangun sebuah
fitur tertentu,
gausah produk ya, fitur tertentu aja.
Dari
dari sisi product owner,
itu pun kita harus diberikan scenario yang jelas
kan. Di setiap
tiketnya, bahasanya.
Setiap tiketnya ada aset-tsekaretnya dan
ada scenario. Senarionya
inilah yang kita terjemahkan
menjadi bagian dari
testing dan testing.
Jadi, semua sudah
klop.
Jadi, waktu testing kita jalan, itu sudah
sudah sebisa mungkin mendekati
aset-tsekretariat
dari sebuah fitur.
Memang, kelihatannya jadi
ribet, jadi rumit.
Tetapi, sekali
dijalankan, sekali
diselesaikan,
kita udah
masih, pas udah punya
apa namanya ya?
- Keyakinan. - Keyakinan, kalau itu
kalau di deploy, itu
- Sudah pasti jalan.
- Besar kemungkinan aman,
gitu ya. Besar kemungkinan aman. Gak perlu
ya, ini gimana, nanti di production
bakal kacau gak ini.
- Itu tadi kayaknya ada yang komen deh, jalan kok
di laptop saya. Tadi ada komennya
"Cari, di-highlight aja."
- Rafki, Rafki. Halo, Rafki.
- Iya.
- Ini mah, apa,
ini hashtag untuk Docker ini.
Nggak ya? - Iya.
- Iya, hashtag universal
development. - Iya.
Apalagi kalau kita kerjanya bareng sama
tim ya, lebih dari satu
orang gitu. Ketika
kita misalkan udah mengerjakan sesuatu,
bersetak tesnya,
terus tiba-tiba ada mungkin ada teman kita yang
lain gitu kan, dia ubah-ubah
ternyata
apa yang kita kerjakan, atau
bug fixing yang kita lakukan, tiba-tiba
di-override sama dia secara tidak
sengaja gitu kan.
Kalau tesnya gak ada, itu kan gak ketahuan
kan. Tapi kalau tesnya ada,
begitu dia push, pas mau dia pull
request, "Oh, ini masih error nih
tesnya." Jadi gak bisa, dia harus
perbaiki dulu. - Kalau jaman dulu kan gak ada pull
request, Mas Riza, adanya
FTP, VFTP upload.
- Tidit langsung di FTP-nya
juga bisa ya. - Berarti itu
harus di-zip kan, versi satu, versi
satu, fix satu,
final, final-final
banget gitu kan. - Saya
mau sharing sedikit apa yang saya lakukan
sebagai
waktu itu develop sebuah
plugin di WordPress, dan plugin ini
digunakan, akan
mau di-launching, soon gitu ya.
Dan waktu lagi develop itu,
karena
justifikasinya, karena timeline-nya
sangat optimistik, gak sempat
untuk bikin tes.
Gak sempat, bener-bener gak sempat
karena banyak yang masih banyak
ditudulisnya gitu,
untuk sampai di titik beta, supaya
bisa di-deploy. Alhasil,
saya-nya yang burn out.
Kenapa? Karena
kriteria dari
plugin tersebut, harus bisa
waktu itu ya, beberapa tahun
lalu, harus bisa jalan di PHP
5.6. Harus bisa jalan
di PHP 7.1,
7.0, 7.1, 7.2.
Harus bisa jalan
di versi WordPress
5 sekian, 5 titik sekian,
5 titik sekian, 5 titik sekian, 5 titik sekian,
jadi ada minimum version yang harus
dijaga. Alhasil,
coba di permutasikan aja. Berarti saya harus
running test-nya manual,
saya harus install plugin-nya,
checking, checking, checking, di PHP
5.6, WordPress-nya
mungkin ada 4 versi,
di PHP 7.0, WordPress-nya 4 versi,
itu jalannya pakai docker memang,
tetapi manual,
manual, benar-benar manual, saya
mengin docker-nya,
install plugin-nya, coba test
klik klik klik, bisa lanjut.
Itu setiap kali mau
release, berarti setiap akhir sprint,
mau dirilis zip-nya
untuk dikasih ke
tim user-nya
bagian sana, untuk
ngetes lagi.
Karena belum punya end-to-end,
dan belum punya fungsional testing,
saya harus lakukan itu semuanya sendiri.
Satu kali melakukan
sebelum kompresi itu
jadi sebuah zip,
saya harus lakukan
test itu 3-4 jam.
Kalau ada satu kali gagal
karena dia fatal error, berarti harus
saya benerin lagi, saya ulang lagi.
Itu semua dari awal lagi.
Jadi sebenarnya,
apa yang saya hemat
waktunya tanpa melakukan testing,
itu sia-sia.
Tapi baik saya awal itu
sudah pikirkan bagaimana end-to-end testingnya.
Yes.
Oke, sebelum kita
ke bagian berikutnya,
ini ada beberapa pertanyaan.
Power Ranger lagi,
saya pernah dapat jawab proyek
kayak testing website aplikasi,
seperti wadah belajar gitu,
kayak misalnya dashboard, dicek
isi-isinya ya,
fitur-fiturnya, apakah itu
yang dinamakan QA?
Maaf banyak yang nanya. Gak apa-apa, kita senang
kalau banyak yang nanya ya.
Itu QA bukan?
Itu QA.
Tapi manual.
Memastikan sebuah
fitur itu jalan apa tidak,
itu namanya QA.
Cuma kan tenaga manusia ya,
yang dipakai sebagai QA,
yaitu punya
beberapa batasan.
Tadi manusia bisa
luput, bisa
gak meriksa bagian tertentu.
Bisa terlalu kompleks juga.
Ya, terus manusia itu buk,
gak didesain untuk hal-hal
repetitif yang
skala besar kan ya.
Manusia dibanding robot,
kelebihannya kita bisa mengkonsep,
kita bisa merancang, cuma kalau untuk
hal-hal yang komputasi yang
skala besar dan repetitif,
ya, capek lah jembul kita.
Jadi apa,
ada titik di mana
QA manual
terbatas, ya udah.
Jadi QA kan cukup luas.
Jadi developer
yang di bidang QA ya biasanya
kerjaannya adalah bikin test suit
dan apa, merancang lah,
mendesain test-testnya.
Ada lagi pertanyaan dari Aman Saputra,
urutan pembuatan testing di tahap apa?
Apa setelah MVP atau
setiap buat function atau fitur baru?
Sebelum MVP. MVPnya
harus ada test juga.
Karena MVP itu adalah
minimum viable product,
bukan produk
setengah jadi atau yang banyak box, ya.
Jadi
MVP itu ya harus berserta
test juga. Kalau mau mengadopsi
gaya test driven development
atau behavior driven
development, berarti testnya duluan, baru
ngerjain code-nya atau
selesaiin fungsinya atau komponennya.
Ya, kembali lagi ditekankan
terserah mau testing
duluan atau testing belakangan, yang penting ada testnya.
Itu aja. Mau MVP,
mau prototype, mau apa,
itu harus ada disertakan dengan
testnya, gitu.
Terus selain
yang tadi kita, yang udah di
artikel tadi kan, baru
yang paling penting ya,
paling basic dari unit testing,
integration testing, nah cuma
terus di web kan ada hal-hal
lain, jadi bisa aja temen-temen
bakal lihat kayak accessibility
testing, itu biasanya pakai
X ya, AXE,
atau DQ ya.
Ya, terus ada juga
seperti visual
testing, visual regression
testing, itu biasanya pakai layanan
chromatic, mereka yang bikin storybook.
Itu banyak.
Storybook dulu. Storybook dulu, ya.
Terus dia diakuisisi
atau gimana sih ceritanya?
Di salah storybook, terus kemudian storybook bikin
chromatic sebagai service-nya.
Oh, gitu. Oh, dia cari duitnya
dari chromatic ya. Storybooknya
sendiri adalah apa? Open source
and free. Ya, itu semua kan
prinsipnya sama, sama kayak tadi.
Jangan sampai ada yang tiba-tiba
berubah, terus pastikan
sesuai kriteria.
Kayak misalnya kalau di accessibility
ya, pastikan user
yang apa? Tuna Netra misalnya
menggunakan screen reader, ya harus bisa
mengisi form-nya juga. Nah, itu
apa? Kita punya assertion
atau ekspektasi, atau harapan, atau
tujuan seperti itu, ya
itu secara otomatis memastikan kode
kita, ya, mencapai
tujuan itu. Terus kalau yang
visual, itu mereka
keren sih. Keren cuma apa?
Berbayar. Jadi ada
gratisannya, cuma terbatas. Jadi
mereka beneran bikin screenshot.
Kalau ada yang tiba-tiba geser,
sekian persen, jadi mereka kayak
mirip mendeteksi CLS gitu deh.
Tapi bukan CLS waktu
di-load ya. Cuma dari
commit 1 ke commit selanjutnya,
kalau ada perubahan dan
kita nggak nge-mark, misalnya kita
nggak meng-update snapshot-nya
dan tampilannya berubah, itu
kita bakal dapet notice.
Kita bisa approve
kalau itu memang intended.
Oke.
Apalagi, apalagi ya jenis
testing-nya, lainnya.
Bikin tentang storybook, ada yang
pernah lihat storybook mungkin?
Atau tombolan?
Coba ya, yang mana nih?
Saya bisa tunjukin ini apa storybook
yang ada di WordPress nih. Oh, boleh-boleh-boleh.
Oh, ada ya? Baru tahu
di WordPress.
Jadi untuk ininya ya, untuk
apa namanya? Untuk
Gutenberg-nya, block editor-nya.
Reakt ya, kalau nggak salah ya?
Iya, dia pakai react. Jadi ini
kan, tahu ya, Gutenberg
punya namanya
apa?
Editor, terus kemudian ini
block editor besarnya, ya.
Elemen-elemen kan ada banyak banget tuh.
Bisa ini, bisa tambah image,
bisa segala macam kan.
Terus, lihat nih, komponennya
segitim banyak nih, komponen semua.
Bayangkan kalau misalnya satu-satu harus
dicek dan CSS. Harus nyalain
PHP ya. Bayangin kalau ngetes-nya
nggak pakai storybook. Iya.
Yoi, lihat ini, ada
inserter komponen, ada
line height control,
ya kan, ada
text transform control.
Ada, terus komponen-komponennya
banyak juga nih.
Animate,
virtualize segala macam kan, ada komponen-komponen.
Dan...
Bisa task state-nya juga ya?
Iya. Terus
bisa color palette misalnya.
Color palette-nya kan juga
komponen sendiri nih.
Color picker.
Itu.
Dan ini,
kalau kita nggak bikin
komponennya di storybook
itu bakal susah banget
di maintain. Jadi yang
dilakukan adalah
komponennya pertama
di develop dulu di storybook.
Jadi, sorry, komponennya
ada di, mungkin di folder
komponen, semua sample, tapi
dijalankannya di storybook. Jadi kita nge-develop-nya
di storybook.
Dan CSS dan admin, segala macam.
Ya, jadi semuanya
itu kita, jadi bukan
kita nge-develop-nya bukan di block editor
utamanya. Kita
nge-develop semua komponen kecil-kecilnya
itu di storybook.
Jadi, namun CSS
dan komponen utamanya tetap berada
di
folder-nya sendiri lah, bahasanya ya.
Kita cuma mau manggil
komponen dan stylingnya itu
di storybook. Jadi, komponen dan
stylingnya itu sudah ter-encapsulasi
hanya untuk di sebuah
komponennya. Jadi sangat,
jadi nggak ada pengaruh
pengaruh antar komponen yang bisa
merusak styling bahasanya gitu ya.
Jadi, semuanya
kita, mereka develop
di dalam sini semua sendiri
sampai,
banyak banget lah, sampai icon lah.
Nah, jika
jika terjadi
dan ini mereka punya regression testing-nya
ya, jadi sampai bahkan
apa namanya, mereka
pasang
ini bahasanya
apa, accessibility, accessibility
test-nya juga ada nih. Jadi,
sudah pas accessibility
testing-nya juga sudah ada.
Jadi, kalau, kan
ini project open source ya.
Semua orang sebenarnya
bisa aja
apa namanya?
Bisa aja
nge-
eh, salah, button book.
Bisa aja nge-develop
full-request
ke sini.
Jadi, kalau misalnya mereka nggak punya
storybook dan testing ini
ya, susah kan?
Dan sedangkan block editor-nya
dipakai berapa juta website
ada kali,
puluhan, ratusan juta website
ya kan?
Nah, jadi accessibility juga harus pass.
Dan ini jalan secara
otomatis.
Mulai dari accessibility
terus kemudian, apa ini
bahasanya, viewport
responsive, responsive-nya juga
juga ditest.
Dan ini otomatis semua kan?
Kalau nggak pas, ya nggak pas
nanti.
Seperti itu.
Nah, storybook juga punya
apa, punya
beberapa tutorial testing buat
mungkin ada teman-teman yang belum pernah
testing sama sekali, terus
bingung mulai dari mana.
Bisa banget tuh tutorial-nya bagus sih.
Walaupun
nanti misalnya
nggak pakai storybook, misalnya
akhirnya karena nggak sempat atau nggak
diperlukan untuk project
teman-teman sendiri nggak pakai storybook, itu
pelajarannya banyak yang
tetap bisa
dimanfaatin.
Karena itu menutup semua area testing.
Berlaku untuk,
bukan hanya untuk storybook ya,
tapi umum ya.
Di situ sih ya, dia pasti integrate
storybook juga, cuma
pelajarannya, caranya flow-nya bisa dipakai
buat project lainnya.
Project yang lain.
Wah, menarik ya.
Oke.
Nah, ini ada pertanyaan bagus nih.
Dari
Isal, kalau TDD itu
test-nya duluan, yang dimaksud adalah
scanner test-nya atau unit test-nya.
Bebas, bisa
macam-macam, tergantung. Kalo
di perusahaannya butuhnya apa,
requirement-nya unit test, ya
TDD-nya unit test. Tapi kalau misalkan
pengennya integration testing, ya
TDD-nya ya integration testing.
Ya, tergantung kebutuhan aja.
Bener gak sih?
Dan biasanya sih, kalo unit test,
ya bikin kayak expect.
Jadi kita bikin failing test dulu.
Biasanya kalo liat dari tutorial orang yang
emang advocate TDD.
Iya, kita nulis,
beneran nulis expect-nya apa,
kita nulis kriterianya, tapi
kan kita baru komponen kosong nih misalnya,
atau baru komponen placeholder, atau fungsi
placeholder yang masih belum return
apa-apa. Jadi emang expectasinya
5 kali running, harus merah,
terus kita tulis kodonya sambil
save sampai hijau.
Habis itu refaktor kalo butuh, ya.
Ada 3 tahapan itu kan.
Kemudian ada pertanyaan dari Yudi.
Bagaimana cara menguji sistem
yang memiliki fungsi kompleks
dan interaksi dengan sistem lain yang tidak dapat
diprediksi secara pasti?
Salah satunya bisa pake
MSW nih. Ini
use case yang bagus buat namanya
mock service worker ya. Kan ga salah lupa
kepanjangannya apa.
Jadi misalnya kita perlu manggil API
atau bahkan misalnya e-commerce
transaksi kartu kredit itu yang
itu kan interaksi sama pihak
keluar dan ga mungkin selalu
setiap kita testing berkali-kali
TDD tadi kita selalu nge-hit
API production atau
service external.
Jadi kita bisa
membuat biar
request kita request ke
URL atau endpoint tertentu
itu ya pake data
mock atau data bohongan.
Cuma ya pastikan
bahwa data bohongannya sesuai dengan data
beneran. Iya. Jadi biasanya kalo saya
pake mock server
pake mock server
ada NPM-nya
pake mock server. Terus saya mock. Jadi kalo
dari
biasanya tanya ya kalo kayak
sekelas visa atau payment
gateway itu mereka udah punya
scenario-nya dan dokumentasi
lengkap tuh response-response error-nya
juga sudah jelas banget ya.
Dan biasanya kan ada kodenya kalo kita pengen dapet
error misalnya decline itu
nomernya 1,2,3,4,5,4
blablabla. Jadi itu membantu
banget buat mocking.
Jadi kita sudah mocking semua tuh dari
success sampe error-errornya semua.
Bahkan yang lebih banyak itu error sebenarnya.
Karena success sudah beberapa.
Success kan ya udah. Success mah udah.
Terus kan macem-macem. Errornya
seratusan gitu ya jenisnya.
Nah kita, aplikasi kita
itu jangan sampe
nge-hit mereka terus-menerus gitu.
Tapi nge-hitnya ke mock service worker ya kita.
Jadi kita set up semua response-nya
yang kira-kira, bukan kira-kira lagi
sesuai dokumentasi
semua response dan error code-nya
kita mock.
Jadi kita nge-hit mock server kita dan
memastikan aplikasi kita
kalo response-nya
A, yang ditampilkan apa?
Response-nya B, yang ditentu apa?
Dan harus ada. Kita manangin itu.
Apa sih kursus kelas namanya?
Payment.
Untuk mock juga
perlu kita
apa ya, kita gunakan.
Terutama kalo misalkan API-nya
dibatasi dengan
trade limit gitu.
Jangan sampe misalkan kita hit ke API
tertentu atau bahkan API yang berbayar
kita setiap kali jalanin test
di hit terus gitu.
Kita selesakan paket ini di tiba-tiba
tagihannya ribuan.
Membengkalkan. Atau
trade limit terus tiba-tiba dia jadi error
malah aplikasinya seolah-olah seperti error
kan. Jadi hal-hal
seperti itu yang pemanggilan ke terparti
API atau ke pokoknya
yang berhubungan dengan
diluar aplikasinya, konteks
aplikasinya itu di
apa ya, mock itu
apa ya, dibikin tier 1-nya.
Seolah-olah kita panggil ke
udah palsu sih, apa ya.
Tier 1, simulasi lah ya.
Seolah-olah kita panggil ke API
GitHub misalkan, tapi
written-nya udah kita tulis aja di kode
kita, jadi seolah-olah aja, pura-pura aja.
Pura-pura.
Pernah ada yang ikut itu nggak sih
coba-coba kayak competitive programming?
Belum.
Kayak main-main aja, main-main
di Hacker, Hacker what? Hacker rank.
Apa? Lead code.
Kalau Hacker rank, code words itu
pernah sih beberapa kali.
Kita dikasih
dikasih
challenge-nya apa,
tapi kan mereka sudah punya test
kesenarionya kan mereka sudah punya kan.
Itu kan sebenarnya
ti-di-di, mereka udah siapin kesenarionya,
siapin challenge, kita nulis kodenya
untuk supaya, kita nulis sampai seperti itu.
Sampai bisa
pas semua
senarionya.
Oke, ngomongin tentang
ini, end-to-end,
ini ada yang minta rekomendasi
tools dari Rico.
Tools JS untuk end-to-end
testing. Tadi udah kita sempat bahas sedikit ya
tentang Cypress.
Ada playwright juga.
Ada playwright dari Microsoft, itu juga
lagi hot ya, lagi panas,
lagi seru.
Ini
cara pakenya tuh
mudah banget.
Ini seru sih, lucu.
Dan kalau kita lihat,
ini tuh malah
mirip sama jQuery.
Kalau dilihat sekilas ya, kayak kita
menarget elemen tertentu, ya
klik aja ini, terus dia bisa
ising juga, dia bisa nunggu setelah klik,
nunggu, terus expect.
Jadi selekturnya itu mirip jQuery banget ya.
Selekturnya bisa
export juga kan?
Bisa, bisa.
Dan ini tutorial-nya bagus, kalau
pernah pake sama sekali,
itu ada tutorial gratis yang
enak buat diikutin.
Playwright sebenarnya lebih
menarik ya.
Lebih simpel lagi.
Ok, kita coba ya.
Apa namanya?
Playwright.
Ini.
Test gitu ya.
Ini, playwright.tab.
Ya.
Mana contohnya?
Docs.
Jalannya di Puppeteer kan nih?
Iya, di atas Puppeteer.
Puppeteer itu apa? Cuma itu semua engine bisa
baik Cypress,
maupun playwright, itu udah support
macem-macem browser engine.
Jadi aman.
Nah, ini contohnya ya.
Bukan cuma Puppeteer kan,
Headless Chromium ya? Ini test ya.
Jadi test, should what?
Should see, should create,
should what?
Jadi ini adalah istilahnya apa?
Scenario ya.
Jadi kita mau tes apakah
ini kita mau bikin
bug report, ceritanya. Mau submit bug report.
Kita bikin new issue dulu
dengan request.post ke repo
dengan user dana repo.
Ke API GitHub gitu ya,
ceritanya ya. Di sini udah ada usernya.
Udah ada repo-nya.
Kemudian kita kirimin datanya, title dan body.
Dan ketika
kita jalankan,
ketika dia selesai posting,
maka kita berharap atau expect
bahwa isunya
mereturn status oke
sama dengan true.
Gitu.
Ini playwright.
Kok kayak nulis unit test ya?
Sedar sana ya.
Sedar sana ya.
Terus kita,
ini kan udah return dari
new issue yang di-postkan.
Terus kita cek juga
bahwa issue ini beneran ada.
Sudah di-submit. Sudah ada di list of issue.
Kita request get
ke repo/issues.
Kemudian kita cek
hasilnya oke atau enggak.
Kemudian kita cek apakah bug report
yang satu, yang sama ini.
Judulnya betul.
Judulnya matching, body-nya juga matching.
Keren ya.
Playwright.
Bagus-bagus.
Semakin memudahkan ya.
Kalau jaman dulu
susahnya setengah mati untuk testingnya.
Dulu kayak gimana sih? Coba cerita dikit.
Selenium dulu.
Taksik kayak gimana?
Dulu itu
salah satu yang
pionernya, pionernya
testing di front-end ya,
bukan back-end ya, testing di front-end
itu adalah angular.
Dia pakai jasmine.
Yang diadaptasi
oleh Jess.
Jess itu ditulis diatas jasmine.
Jaman dulu masih pakai Pantom Jess
kan ya? Iya.
Pantom Jess.
Saya kenal tuh orangnya yang bikin.
Pantom ya, Pantom.
Terus abis itu baru masuk
ke selenium kan untuk yang end-to-end
untuk integrationnya
masih di jasmine.
Dan jasmine itu yang
serunya adalah, mungkin sampai
sekarang juga, mungkin masih beberapa, masih ada
yang pakai, dia bisa jalan di
browser, nggak perlu pakai note.
Karena dulu belum
si angular pun dia nggak pakai
note kan, dia pakai CDN-CDN aja bisa
gitu kan. Jadi nggak perlu ada
install note di lokal,
tinggal tambahin CDN, jasmine nanti tambahin
juga udah bisa bikin test suite
di sana. Terus jalaninnya pakai lokal
skian-skian/test misalkan, abis itu
nanti dia akan ngetest
aplikasi kita. Itu mulai
awalnya dari sana.
Itu sebelumnya tuh
testing di
front-end tuh, ya paling apa
jQuery.test itu.
Apa namanya? Lupa.
Itu lah ada. Tapi itu lebih ke unit test
ya.
Untuk testing library-library-nya.
Lebih dulu lagi
itu langsung jalaninnya di browser.
Jadi yang saya lupa
pakai Selenium. - Kalau nggak jalan, berarti salah.
- Bukan, Selenium gitu. Jadi bisa kayak
web browser, kita
record misalnya.
Kita record dulu, kita
record, klik-klik-klik, klik-klik-klik,
jadi kayak end-to-end gitu. Kita klik
dari awal sampai habis, kita masukin
name and passwordnya, jadi
di-play. - Oh, di-record ya?
Kayak ini ya? Kayak
patir record gitu ya?
- Kalau saya lupa namanya,
kalau yang terbaru, saya liat namanya
Ghost Inspector yang mirip.
Ghost Inspector di
Firefox. Tapi mirip.
Jaman dulu saya lupa namanya apa.
Jadi
kita nge-record
kliknya kita, misalnya
mau login, kita masukin password,
segala macam. - Nanti dibikin script sama dia.
- Nanti tinggal di-play. Kalau ada yang gagal,
kalau ada yang gagal,
dia akan bilang gagal.
Dan itu, senarionya udah banyak.
Tapi nggak pakai
kayak web recorder itu dulu
bukan untuk ini sih,
bukan untuk ngetest, tapi
untuk mencurangin sebuah sistem lah
misalnya. Kayak
nge-click ads misalnya.
- Dulu belum ketahuan ya?
- Belum. Kan pakai VPN.
Dia pindah-pindah.
- Diajak IP-nya.
Malah ngajarin kriminal.
- Untung nggak ada Mas Danang nonton, kan?
- Eh, siapa bilang?
Sekarang dia muncul.
Ya, jadi sebenarnya
sekarang tuh udah enak banget
testing-nya. - Apalagi kalau kita
pakai, gimana-gimana?
Laluan aja. - Iya.
Kemarin pengalaman udah lama
nggak cobain spell kit, cobain
lagi kan yang versi baru.
Cobain di project baru, itu udah
ada NPM test
titik 2 unit untuk unit test.
Yang Cypress-nya juga udah disetupin.
Play rate-nya juga ada.
Jadi udah tinggal jalanin aja.
- Nah itu, kita pakai meta,
kalau kita pakai meta framework, kayaknya
sebagian besar meta framework modern
udah include. Kayak swell kit kan
kalau kita pakai official starter tuh
yang pakai apa? NPM
create swell itu dedikasi
opsi, cuma emang opinionated.
Karena dia pakai fit,
unit testing-nya
pakai fit test.
Terus kalau apa, end-to-end-nya
pakai play rate.
Iya, kalau kita mau pakai yang lainnya, bebas.
Cuma kalau dengan
bawaan official starter kan kita
beneran nggak usah repot-repot
konfigurasi apapun ya, langsung jalan.
Di Next.js juga sama.
Ada contoh-contohnya malah itu
bisa pilih mau pakai Cypress,
mau pakai play rate.
- Iya, terutama
waktu instalasi play rate ya,
saya baru pertama kali pakai kan, begitu
dijalankan dia error, karena
play rate-nya belum keinstall.
Tapi install play rate-nya pun sederhana sekali.
Gak kayak dulu kalau misalkan,
"Woh, kita harus pakai, harus install
Chrome driver-nya dulu, masukin ke folder ini."
Gitu kan. Sekarang udah diinstallin
kayak NPM-nya. - Untung nggak ngalamin.
- Enak banget.
- Nggak tahu kalau framework lain ada nggak ya
kayak Nux segala macem, ada yang otomatis
nggak testing-nya?
- Testing-nya.
Kita coba lihat. Ini contohnya
mana nih? Manual setup.
Nah, ini udah ada dia biasanya, Cypress.
Cypress juga ada
UI-nya ya, jadi kalau Cypress open,
dia ada GUI.
- Iya, dia otomatis buka di
localhost.5432 atau
semacamnya lah, punya protocol
sendiri. - Nah, ini Cypress
seperti ini nih. Ini integration testing ya
contohnya ya.
Jadi kita visit ke localhost, ini udah
mirip seperti yang kita lakukan
tapi secara otomatis.
- Ini end-to-end. - Terus like elemennya
kayak jQuery kan?
- Ini end-to-end, sorry. Ini end-to-end, bukan
integration.
Ini end-to-end. Jadi... - Ini simpelnya ya.
Ini end-to-end. - Iya.
- So navigate into the about page gitu.
- Ya, terus ke apa?
- Dari about page ini,
di-check apakah ada link
yang isinya adalah about.
Abis itu bisa di-click.
Ya, bisa di-click.
Terus abis itu, setelah di-click, apa yang kita
harapkan? - Setelah di-click, artinya harus berubah.
Harus berubah jadi /about.
- Berisi about.
- Dan ada h1 dengan
isinya adalah about page ini. - Isinya harus about page.
- Betul.
- Biasanya lebih enak kayak senior-nya bikin
test krenalialnya, junior-nya
bikin kodenya semua.
- Eh, tapi dulu ada tuh
tools yang
kita bikin skenario-nya bahasa
Inggris, terus dia bisa convert jadi
seperti ini. Jadi test skenario.
Namanya apa ya?
- Ada tuh... - Cucumber.
- Cucumber. - Cucumber ya.
- Cucumber itu apa ya? - Cucumber GS.
- Cucumber GS.
Ada nih Cucumber.io.
- Di
Ruby, kalau nggak
salah. - Cuma dia
bahasanya apa? Language.
- Language-nya bahasa Inggris. - Bahasa Inggris ya.
Bahasa Inggris. - Bisa bahasa Inggris ya?
- Bahasa Indonesia. - Bahasa Indonesia.
- Wah keren. - Nggak tahu.
Bisa bahasa Inggris tahu saya. - Bahasa Inggris lah.
- Iya bahasa Inggris tuh. Namanya
Gherkin Syntax. - Gherkin, iya iya.
Jadi dia ini khusus untuk kayak BDD.
Jadi yang bikin
Syntax Gherkin-nya ini bukan orang
developer, tetapi bagian test.
- Produk manager ya?
- Produk owner lah. - Ini nanti bisa di-confort.
- Saya ingat di depan mereka bikin sekali.
- Coba bayangkan kita
bikin ini
pakai chat GB.
- Pakai chat GB.
- Enak banget.
Ada yang bikinin test buat kita ya.
Cucumber.io.
Ya ini bener kan.
Jadi skenario-skenario-nya
saya pengen
apa. - Wah kita kena
kita kena spam nih.
- Oh di spam. Pertama
kaya prestasi nih rekor.
Pertama kali kena spam buat.
- Tapi spamnya. - Ayo.
Jangan di-click ya teman-teman.
Insinya bukan Beautiful Girls
kok. Nanti malah di...
- Wah berarti ini kita rame
ya. Sampai ada spam segala ya.
- Oh iya. - Kena spam
buat. - Oke. Dari skenario ini
di...
seolah-olah ya. Ini, ini gak, gak
ini ya. Jadi seolah-olah dia akan
apa, dijadikan,
dikompilasi menjadi ini.
Atau ini yang eat ini.
Terus kemudian when ini adalah
ketika kondisi
tertentu. Ya misalkan ini.
Ketika ada tombol
atau ada link, maka di-click.
Kemudian then
dan itu adalah harapannya.
Maka dia akan menjadi ini.
Ini adalah URL tentang...
- Wih ada dua.
Block lah. Block, block, block.
Block juga. - Bisa. Saya gak tahu.
- Bisa lah.
- Oh bisa langsung dari
ini ya. - Dari Streamyard.
Ternyata bisa.
- Ini baru, baru pernah.
Harap ngaku. - Iya.
Oke.
- Beda, beda access.
- Ini ada yang, ada yang Javascriptnya gak sih?
- Ternyata beneran, ada Javascriptnya
dan ini ada, ternyata beneran
ada localization. Jadi
emang bisa menulis pakai
bahasa Indonesia dan bahasa lainnya.
- Nice, localization.
- BDD tuh, BDD.
Eh ada Mas Dan. - Bener kan ada Mas Dan kan?
- Ayo lho.
- Jangan gagal lho.
- Ivan tadi Mas Ivan.
- Langsung diem.
- Langsung diem.
- Gomit.
- Mana contoh yang JS ya? Pengen tahu.
Gampar yang JS.
10 minit tutorial.
Kelamaan.
- Ada tadi JS di halaman
depannya landing page-nya. - Oh halaman depannya.
- Oh di installation.
- Oh installation.
Oke.
- Di paling atas. - Wih.
Baru gabung. Oh gak apa-apa gak denger dia.
Aman, aman.
Langsung penasaran Mas Dan
yang tadi paling ngomong apa.
- Langsung diem.
Langsung dicek.
- Tuh ada Java,
JavaScript, Ruby,
dan 99.
- Oh iya. Ini JS nih.
Cucumber. Terus gimana cara ininya?
Oh ini baru install ya?
Guides berarti ya. Bener ya.
Guides-nya yang
JavaScript gak ada ya?
Ini apa?
- Oh.
Oh iya.
Wah harus kita ini lagi ya.
- Ini bisa
dimasukin si ICD juga ya?
Oh iya itu poin
bagus tuh. Apapun itu,
gak harus pakai Cucumber.
Sebisa mungkin testing kita ya
digabungkan dengan
workflow kita. Kalau yang paling
simpel nih, pakai Git Hux
dulu. Git Hux tuh misalnya yang terkenal
Husky ya. Jadi apa?
Entah kita
ngubah codingan kita yang sebelumnya
kan pertama bikin biasanya masih rapih
banget tuh. Rapih ada testingnya.
Nah besok-besoknya udah buru-buru ya udah
sembarang
diubah tanpa
kita ngurusin testingnya atau mungkin
teman kerja kita yang ngubah. Nah
dengan Git Hux kita bisa ngatur
tiap commit atau
tiap mau push harus
running semua dari
static analysis juga bisa
format, pastiin semua konsisten
juga bisa ngejalanin
testing, biasanya unit atau
integration test. Jadi kalau itu fail
ya kita harus
handle itu dulu. Buat mencegah
yang tadi tuh bug pertama dibenerin
muncul bug kedua, bug kedua
dibenerin, bug pertama balik
nah itu bisa dicegah dengan pertama
Git Hux. Terus kedua bisa juga
si ICD kayak misalnya kalau
pakai GitHub Actions atau
Travis atau dan lain-lain.
Cypress kalau nggak salah punya
layanan, punya layanan
berbayar juga ya cloud kayaknya.
- Oh untuk itu ya
untuk CIN-nya ya?
- Jadi untuk dihook ke proses
workflow CICD kita.
Jadi intinya jangan sampai kita nge-deploy
yang belum lulus. Pertama
jangan sampai kita meng-commit kode
yang belum di-testing.
Kedua jangan sampai
nge-deploy kode yang belum di-testing
yang bisa, yang bisa rusak
bisa lembak.
- Ini juga buat apa?
Gimana gimana?
- Cuma mau bilang hati-hati
kalau GitHub Action itu
yang freenya cuma ada limitnya.
- Iya.
- Karena kalau kebanyakan
ngetes itu
naik loh GitHub Action
hours-nya. Hati-hati.
Jadi perlu diperhatikan juga soal billing.
- Iya.
Ini juga berlaku
buat kasusnya Ivan tadi ya
untuk ngetes
PHP versi skian, PHP versi skian
itu bisa DCI juga kan?
- Iya. Sekarang sudah
plugin itu udah di-handle sama tim lain
dan itu sudah dibikin. Udah pakai
parallel testing malah
supaya udah
dibikin permutasi tuh PHP
yang sekarang supportnya
74 dan 8 doang
dan WordPress versionnya
4 terakhir. Jadi
sudah dibikin permutasinya langsung.
Begitu PR-nya naik
dan dilabelin apa
dilabelin misalnya review
baru dia jalan.
Dan sekali jalan, langsung sekali
10 instance itu sekali jalan
otomatis ngetes.
Jadi kalau nggak pas
tesnya, nggak direview kodenya.
- Nggak direview.
Ini saya pespa tadi ya?
- Iya. - Jadi itu bagus
buat produktivitas juga kali ya.
Jadi, kalau pun ada orang yang
developer yang not QA
atau ngereview manual
atau senior engineer yang ngereview manual
kan yang nggak buang-buang waktu juga bolak-balik ngereview
kode yang masih ada
obvious error-nya.
- Yes, betul.
Ini tadi saya
press cloud-nya.
- Ada free plan-nya ya?
Ada
gratisan, cuma terbatas 500
tes sebulan.
Ada storybook sama chromatic.
Chromatic itu juga bisa visual
regression setting-nya.
Dan snapshot test-nya juga bisa dilakukan.
Enaknya pakai chromatic, dia bisa
collaboration.
Jadi, kalau misalnya ada...
Jadi kalau misalnya kita punya
komponen,
misalnya CSS-nya berubah, terus kita kayak
dia kayak kegeser
1 pixel jadinya.
Karena padding-nya masalah.
Jadi,
harus ada yang nge-approve.
- Betul nggak? Gak apa-apa nih.
Gak apa-apa nih kegeser 1 pixel.
Harus ada yang bertanggung jawab.
- Atau memang sengaja.
Mungkin perubahan font, perubahan
perubahan size.
Memang perubahan yang disengaja.
Harus ada yang approve.
- Kalau perubahan, apa, geser 1 pixel
di snapshot
nggak bisa
ketangkap ya?
Di mana?
Perubahan di mana?
- Yang perubahan 1 pixel itu.
- Kalau di snapshot, kelihatan.
- Maksudnya, apa, pakai
jes snapshot?
- Jes nggak bisa kelihatan kalau perubahan.
- Ya, ada yang ngebaca domlo doang.
- Kalau jes nggak ada...
Jes itu ngebaca markup.
- Oke, oke, oke.
Oke, tadi...
- Tapi jes bisa
nge-snapshot juga kalau mau ditambah.
- Oh, bisa.
- Jes bisa nge-snapshot.
Bukan nge-snapshot dom ya,
dia nge-snapshot beneran.
- Bisa, bisa, bisa.
- Bisa di-save ke gambarnya.
- Jalanin Papetir atau gimana?
- Jalanin Papetir.
- Ya.
Oke, tadi sempat kita bahas
tentang meta framework.
Next bisa menggunakan baik
sidepress ataupun playwrite
ataupun feed kalau untuk
unit testing ya.
Kemudian bisa
pakai jes juga tentunya.
Terus ada lagi Astro.
Astro juga sama.
- Cuma dia belum
ada, belum bawaan.
Jadi nggak bisa langsung, cuma ada
guide-nya ya minimal.
- Sudah ada guide-nya, betul.
Kalau SvelteKit,
terakhir saya cek, belum ada
di dokumentasinya.
- Cuma malah ada di official starter-nya ya.
- Iya, walaupun di
project yang kita create, itu ada.
Tapi mungkin belum, ini kan SvelteKit kan
belum, masih projectnya
bisa dibilang, masih beta ya.
Belum beta satu. - Beta terus, dari kapan tahu?
- Iya. Jadi mungkin
belum lengkap lah, gitu. Cuman
pas coba jalanin
projectnya, itu udah ada NPM test dan lain-lain,
udah lengkap semua. Cuma
belum ada guide-nya aja. - Belum, dokumentasinya
belum lengkap. Tapi udah bisa
berjalan.
- Nanya agak OOT, boleh lah.
Satu, dua pertanyaan OOT, boleh ya?
Kita jawab nanti ya.
- Apa, yang menang Piala Dunia?
- Yang menang Piala Dunia.
- Masa nanya OOT,
nggak boleh?
- OOT.
OOT.
Bisa buat topic itu, OOT.
- Bisa buat topic. Oh iya, tapi ada yang
suggest topic juga nih.
Ada yang suggest topic nih, mana tadi?
- Micro-service.
- Oh, micro-service.
Kalau di front-end namanya
micro-front-end.
- Micro-front-end.
- Eh itu tuh banyak yang tanya ya.
Aku pas di Devast Bali kemarin juga
ada yang tanya itu. Cuma karena waktu
Mepet ya nggak bahas detail juga.
- Oke. - Jadi kayaknya
emang interest di micro-front-end
makin naik ya.
- Kenapa tuh?
- Micro-front-end tuh apaan sih?
- Front-end tapi kecil-kecil.
Packagenya.
Itu perspektifnya macem-macem sih.
- Komponen dong.
Komponen.
- Ada yang kasus ekstrim, satu repo,
satu komponen.
Itu kasus yang paling ekstrim.
Nah, terus
alternatifnya lainnya, ada gini nih,
biasanya e-commerce besar,
itu, jadi satu tim misalnya
section buat checkout,
product checkout, card and checkout,
itu satu repo sendiri,
satu repo front-end sendiri,
terus kayak product display,
buat browsing product ya,
buat browsing product, satu repo sendiri,
terus buat kayak dashboard,
misalnya user bisa login,
bisa lihat history,
itu satu repo sendiri,
satu project sendiri.
Itu kalau yang banyak artikel,
terus sih Zalando, jadi mereka itu
kelihatannya e-commerce besar
di Eropa.
Terus yang konon pakai micro-front-end
juga itu Spotify, Ikea,
cuma kalau itu sih nggak
terlalu di-open ke public,
apa perspektifnya,
apa arsitekturnya kayak gimana.
- Repo lah yang muka kayaknya.
- Saya dulu pakai ini malah, satu repo,
tapi multiple package.
Jadi di-handle semua
pakai Lerna.
- Oh Lerna.
Itu mono repo kan? Bukan?
- Iya mono repo, tapi
kita pakainya Atomic Design.
Jadi setiap
atom, setiap komponen,
jadi ada dari atom,
organism, atom,
molekul, organism, segala macam itu
jadi
jadi satu
package sendiri, DNPM package.
Jadi saat mau di-import,
tinggal import
molekul-molekulnya aja.
- Oh iya, kalau yang Zalando itu lupa sih
repo-nya terpisah atau nggak,
mungkin mono repo ya, cuma maksudnya
tadi satu project, satu package.
Nah ini yang
OOT tanya apa, nggak tanya-tanya.
- Iya, silahkan
ditanyakan. Nah ini salah satu contoh
micro front-end dari Paypal. Paypal
juga micro front-end ya,
jadi ada timnya karena
udah banyak,
jadi misalkan dia, ada contohnya nggak sini ya?
- Nah itu front-endnya cuma satu?
- Ini masing-masing
yang warna biru, kuning,
merah, sama abu-abu ini
itu adalah aplikasi masing-masing.
- Satu tim, satu project.
- Iya, bahkan menu pun satu project
sendiri bisa aja
framework-nya beda-beda.
Misalkan ini pakai view, ini pakai
spelt misalkan ya.
Atau apa, itu tergantung sama
timnya.
- Terus gabunginnya, yang ngegabungin
semuanya satu project sendiri? - Ada, ada satu lagi.
Dan yang menariknya adalah
yang menulis
artikel ini adalah mas Bimo, orang Indonesia
yang bekerja di Paypal.
- Nice.
Kapan bisa diculik kesini?
- Jauh ini. - Nggak, nggak, nggak.
Terlalu jauh itu.
Kemarin waktu di Makassar ada
GDE baru kita namanya
Dana, dia juga bahas tentang micro front-end
dimana deploy ke Firebase
hosting. - Wah seru itu.
- Dia di Bukalapak dan Bukalapak juga
menggunakan micro front-end.
- Oh, biasanya berarti banyak di e-commerce ya
keliatannya. - Iya.
- Karena skop mereka besar.
Iya, seru nih.
- Bisa, bisa, bisa.
Terima kasih ya.
Masukkan untuk topiknya ya.
Terima kasih. Kita masih nunggu
pertanyaan OOT ini
dari Mas Drian.
Ayo ditunggu. Kita udah satu jam 14 menit.
Kita tunggu 1-2 menit.
Kalau nggak ada, ya berarti kita
sudah dulu saja ya kali ya.
Ini ada testimoni ini ya.
Tistemoni, luar biasa ya.
- Mantap.
Swelt itu emang nagih sih.
- Alhamdulillah, udah bisa bikin
beberapa project, baik itu pakai spell
atau spel kita. Iya.
Seru, seru, seru.
- Sekali pakai Swelt, pas balik ke
React lagi sedih set-state
sama use effectnya.
- Loh, Eka kan sehari-hari
React nggak? Atau apa?
- Ada React, ada Swelt.
- Ada Swelt juga? Oh, oke.
Jadi, merasakan ya?
- Kita bahas lah itu.
Why the world doesn't need,
why the world may not need React.
- Virtual Dumbo.
Tiamuk masa.
- Tiamuk masa.
Masanya lagi banyak.
- Isu Sarah, Swelt, Anggular, React.
- Kan ego-ego itu.
- Siapa yang dari React itu?
Yang bikin Redux?
- Yang bikin Redux.
Dan Abramov.
- Kan dia bilang you may not need Redux.
- Iya, padahal dia yang bikin ya.
Dia bikin sampai
di-hire. Dia soalnya bikin
sampai di-hire Facebook, abis itu udah dia nggak perlu
Redux lagi, udah.
Videoannya itu dia.
Buat di-hire aja.
Pertanyaan tidak kunjung datang,
kalau begitu, mungkin...
- Oh, kalau mau tanya, bisa ke Slido, ya?
- Oh, iya betul.
- Bit.ly/ngobrolinweb.
Silahkan, mau oot gimana juga nanyain, boleh?
Kecuali nanyain nomor handphone, ya?
Jangan, ya?
- Boleh nanya, tapi nggak dijawab.
- Nggak dijawab?
- Oh, iya, iya.
Baiklah.
Kalau begitu,
untuk malam ini, kita
kemudahan dulu.
Terima kasih buat teman-teman semuanya yang sudah hadir,
yang sudah
menemani.
Diskusinya cukup seru. Malam hari ini cukup rame.
Sampai ada spam segala, ya.
Jadi, pencapaian baru.
Terima kasih, kita ketemu lagi.
Insya Allah ketemu lagi minggu depan.
Saya Riza,
Pamit, Eka, dan Ivan
juga Pamit. Selamat malam, selamat istirahat.
Selamat malam! Bye!
Deskripsi asli dari YouTube
Yuk mari kita diskusi dan ngobrol ngalor-ngidul tentang dunia web. Agar tetap up-to-date dengan teknologi web terkini. Topik, tautan dan pertanyaan menarik bisa dilayangkan ke https://bit.ly/ngobrolinweb Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
2 Jul 2025
Ngobrolin Storybook
Episode ini membahas Storybook, tool untuk membangun, menguji, dan mendokumentasikan komponen UI secara terisolasi. Host...
9 Apr 2025
Bedah Situs
Episode ini merupakan edisi perdana segmen "Bedah Situs" di mana tim Ngobrolin WEB mengulas website mereka sendiri, yait...
23 Jul 2025
Bedah Buku Problem Solving 101
Episode ini membahas buku "Problem Solving 101" karya Ken Watanabe, mantan konsultan McKinsey yang menulis buku ini seba...
Suka episode ini?
Episode baru setiap Selasa malam. Dengarkan lewat YouTube, Spotify, atau feed podcast favoritmu.
Memuat komentar dari GitHub Discussions...
Jika komentar tidak muncul karena ekstensi privasi / adblocker, kamu bisa berdiskusi langsung di GitHub Discussions .